0

gradle init creates a number of files in the working directory: "settings.gradle.kts", "gradlew", "gradlew.bat", "build.gradle.kts", and the "gradle" directory. I prefer to have a cleaner working directory, can I just keep the "build.gradle.kts" and delete the rest?

With a "hello world" Java application, I can just start it with "gradle run", is there any critical functionality that I will miss later on?

Tamara Koliada
  • 1,200
  • 2
  • 14
  • 31
Konrad Höffner
  • 11,100
  • 16
  • 60
  • 118
  • 1
    The `gradlew` scripts are the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html); the recommended way of running Gradle within your project. It ensures everyone working on the project (and you between software updates) uses a consistent version of Gradle to build the project. – MTCoster Feb 15 '19 at 15:52
  • 1
    [2/] `settings.gradle` (or `settings.gradle.kts`) is [part of your build script](https://stackoverflow.com/a/45388817/1813169), and finally the `gradle` directory contains everything from temporary build files to cached libraries. While not essential, it’ll be regenerated every build and builds will execute faster if you leave it intact. – MTCoster Feb 15 '19 at 15:57

1 Answers1

2
Component        || Keep?
-------------------------
build.gradle     || Yes
settings.gradle  || Yes
gradlew          || Yes
gradlew.bat      || Ideally
.gradle          || No

It's considered best practice to check in gradlew into the code repository. Reason: other developers, testing tools, build tools will get to use the exact same build configuration as you did on your local - thus ensuring consistency and not causing surprise issues that need to be debugged individually.

For multi-project code repositories, top-level has one settings.gradle while each sub-project should have their own build.gradle. For multi-project repositories, top-level directory can also have a build.gradle which is meant to be a way of maintaining common plugins and dependencies for all the subprojects.

settings.gradle establishes project structure, names of modules, name of top level roots, etc. While build.gradle is expected to contain plugin requirements (how should these tests run?, how to get coverage report?) as well a set of dependencies that the project needs.

The gradlew.bat file is the gradle wrapper for windows systems -- for full hygiene, I'd check it into VCS, but if you are only concerned with *nix ecosystems, you should be able to remove this file.

Now, going back to the first point I made, depending on the system you are on, gradle init might produce a different gradle wrapper that might interact with these files in unexpected ways. Hence, it is good practice to check them all into VCS.

I would definitely not check in the .gradle or /build directories - it contains bunch of caching and files for temp build steps. These things should be in .gitignore to ensure optimal local developer speed, but there's not much sense in putting this stuff in VCS.

Debosmit Ray
  • 5,228
  • 2
  • 27
  • 43
  • Coming from other build systems like Maven or npm, I wonder why a single configuration file (pom.xml, respectively package.json) is enough and a wrapper is not needed there. Why is this different with Gradle? – Konrad Höffner Feb 18 '19 at 08:45