Adding gradle wrapper files to gitignore

Help/Discuss
1

Why are people checking in these files to git?
gradlew
gradlew.bat
gradle/wrapper/gradle-wrapper.jar
gradle/wrapper/gradle-wrapper.properties

I have added these files to .gitignore. I don’t like having such files to VCS.

The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary.

I see projects having commits where the gradle-wrapper.properties gets updated with new Gradle version, and a JAR file in the git repository is a monstrosity.
Like this one: https://github.com/gradle-guides/building-java-9-modules

They way I see Gradle Wrapper it is a “download manager” for Gradle and a “wrapper” for the gradle executable. You would need to continue to use the Gradle Wrapper if you want to use the distributions it downloads, instead of the system installed Gradle.

I see no point in checking in these files. They can be generated just by calling gradle wrapper. If all you need is to set a gradle version for the project, why not just put it in settings.gradle and have it used when calling gradle wrapper.

Having to make commits like this one is ridiculous.
https://github.com/javafxports/openjdk-jfx/pull/92/commits/0a32097ed211cb358d3c02c638fe5e73929e4d76

2

Hey
the gradle wrapper files are meant to be stored along with the other sources of your project in the version control system. the two main benefits of using the wrapper:

  • Standardizes a project on a given Gradle version, leading to more reliable and robust builds.
  • Provisioning a new Gradle version to different users and execution environment (e.g. IDEs or Continuous Integration servers) is as simple as changing the Wrapper definition.

If you would have just run the wrapper task as provisioning step to install the proper gradle version, you would still rely on the fact that you need gradle to invoke this wrapper task. a chicken egg problem so to say. instead the wrapper scripts don’t require any gradle installation on the machine they’re executed. We also work hard to keep the wrapper jar as small as possible.

More information about the wrapper can be found in the according user guide at https://docs.gradle.org/current/userguide/gradle_wrapper.html

Hope that helps,

cheers,
René

2 Likes
3

René Groeschke, it is true what you say, however placing binary files under source control makes it harder to reason about IP infringement or malware.

Then it is hard to tell if wrapper.jar was tampered or not. Well, I just figured out there’s https://docs.gradle.org/current/userguide/gradle_wrapper.html#wrapper_checksum_verification , however the page might go away or just get moved.

Do you think it is a viable option to distribute “wrapper” in a source form? Then ./gradlew could just compile it in case the jar is missing.

Well, GradleWrapperMain depends on org.gradle.cli.CommandLineParser, so “source wrapper” could be like org.gradle.cli (36KiB) + org.gradle.wrapper (45KiB).

Alternative option could be to publish current wrapper side by side with “main Gradle distribution”, and use “thin wrapper” do download true wrapper. We don’t need org.gradle.cli in a thin wrapper.
On the other hand, 80KiB is more or less close to the size of the current wrapper.jar (which is ~55KiB), so even plain source format would be OK.

Is it something that can be merged into Gradle?

A dumb compile&jar takes ~3 seconds for me, so it should probably be fine (the produced gradle-wrapper.jar would be reused on subsequent ./gradlew calls):
javac @files.txt -d out && jar cf gradle-wrapper.jar out

2 Likes
4

I agree that placing compiled binary files into a source repository is not an option (because VCS is for sources files when a jar with compiled classes is not a source file at all).

As can I see, the only reason to use Gradle wrapper is to specify its version (please correct my if I missed something). So is it possible to manage Gradle somehow to specify its version without putting jars into the sources repo? Do shell scripts or Ant help?

Thanks

5

@Leo326, Gradle wrapper does an important job of verifying the downloaded Gradle binary (see distributionSha256Sum in gradle-wrapper.properties)

6

A solution that would reflect that

  • binary files are not welcome in VCS
  • and downloaded binary wrapper needs to be verified

could be

  • introduction of gradle/wrapper/gradle-wrapper.java that would make sure that gradle/wrapper/gradle-wrapper.jar is available and if not, it would download it and perform checksum verification. gradle-wrapper.java could be executed directly from source - JEP 330: Launch Single-File Source-Code Programs. This allows to perform download and verification in platform independent way. (Maybe gradle-wrapper.jar could be moved to different location so that gradle/wrapper/ directory can be still tracked by VCS.)
  • Alternatively signed jars (as described at Signing and Verifying JAR Files (The Java™ Tutorials > Deployment > Packaging Programs in JAR Files)) could be used. Again downloading of gradle-wrapper.jar in case it is missing, could be handled by newly introduced gradle/wrapper/gradle-wrapper.java.
7

I think it’s a great idea. With the introduction of java 22 JEP 458 it looks even easier to implement. I hope developers can consider this option.