# Adding gradle wrapper files to gitignore **URL:** \ **Category:** Help/Discuss\ **Created:** [June 20, 2018, 5:28pm UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428 "2018-06-20T17:28:46Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![DJViking](https://avatars.discourse-cdn.com/v4/letter/d/ecccb3/32.png) [@DJViking](https://discuss.gradle.org/u/DJViking)\ **Post date:** [June 20, 2018, 5:28pm UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/1 "2018-06-20T17:28:46Z")
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](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](https://github.com/javafxports/openjdk-jfx/pull/92/commits/0a32097ed211cb358d3c02c638fe5e73929e4d76) ---
**Author:** ![Rene](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/rene/32/8082_2.png) [@Rene](https://discuss.gradle.org/u/Rene)\ **Post date:** [June 21, 2018, 6:37am UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/2 "2018-06-21T06:37:21Z")
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](https://docs.gradle.org/current/userguide/gradle_wrapper.html) Hope that helps, cheers, René ---
**Author:** ![vlsi](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vlsi/32/7535_2.png) [@vlsi](https://discuss.gradle.org/u/vlsi)\ **Post date:** [March 15, 2019, 7:04pm UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/3 "2019-03-15T19:04:59Z")
[René Groeschke](https://discuss.gradle.org/u/Rene), 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](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 ---
**Author:** ![Leo326](https://avatars.discourse-cdn.com/v4/letter/l/439d5e/32.png) [@Leo326](https://discuss.gradle.org/u/Leo326)\ **Post date:** [August 6, 2020, 11:03pm UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/4 "2020-08-06T23:03:53Z")
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 ---
**Author:** ![vlsi](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vlsi/32/7535_2.png) [@vlsi](https://discuss.gradle.org/u/vlsi)\ **Post date:** [August 10, 2020, 8:59am UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/5 "2020-08-10T08:59:06Z")
> [@Leo326](#): > > As can I see, the only reason to use Gradle wrapper is to specify its version (please correct my if I missed something) @Leo326, Gradle wrapper does an important job of verifying the downloaded Gradle binary (see `distributionSha256Sum` in `gradle-wrapper.properties`) ---
**Author:** ![czerny](https://avatars.discourse-cdn.com/v4/letter/c/f9ae1b/32.png) [@czerny](https://discuss.gradle.org/u/czerny)\ **Post date:** [October 20, 2021, 11:19am UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/6 "2021-10-20T11:19:55Z")
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](https://openjdk.java.net/jeps/330). 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)](https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html)) 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`. ---
**Author:** ![maeln0r](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@maeln0r](https://discuss.gradle.org/u/maeln0r)\ **Post date:** [April 19, 2024, 10:21pm UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/7 "2024-04-19T22:21:11Z")
I think it’s a great idea. With the introduction of java 22 [JEP 458](https://openjdk.org/jeps/458) it looks even easier to implement. I hope developers can consider this option. ---
**Author:** ![Glavo](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/glavo/32/9783_2.png) [@Glavo](https://discuss.gradle.org/u/Glavo)\ **Post date:** [August 27, 2026, 8:06am UTC](https://discuss.gradle.org/t/adding-gradle-wrapper-files-to-gitignore/27428/8 "2026-08-27T08:06:35Z")
I developed a project called Gradle Wrapper Neo: [https://github.com/Glavo/gradle-wrapper-neo](https://github.com/Glavo/gradle-wrapper-neo) It provides a `GradleWrapperNeo.java` source file as a replacement for `gradle-wrapper.jar`, so that no binary files need to be committed to the Git repository. On the first invocation, the `gradlew`, `gradlew.bat`, or `gradlew.ps1` script compiles `GradleWrapperNeo.java`, packages it into a JAR, and caches the result in a temporary directory within the project. As a result, subsequent startup performance is comparable to `gradle-wrapper.jar`, without incurring the compilation overhead on every invocation of `gradlew`. We have already started using it in projects such as [HMCL](https://github.com/HMCL-dev/HMCL) as a replacement for the standard Gradle Wrapper. It has been working very well and integrates smoothly with IDEs such as IntelliJ IDEA, as well as with `gradle/actions/setup-gradle`. So far, we have not encountered any issues.