skip to content

After upgrading, which wrapper files must be committed and why does committing them matter for the team?

level: middleimportance: should knowfreq 45%

answer

  1. properties + jar + gradlew + gradlew.bat
  2. repo carries its own build tool
  3. reproducibility / CI parity
  4. distributionSha256Sum for integrity
  5. don't gitignore the wrapper jar

basics

~10 s

Commit all four: gradle-wrapper.properties, gradle-wrapper.jar, gradlew, and gradlew.bat. Together they guarantee every developer and CI run uses the exact same Gradle version with zero manual install.

solid answer

~40 s

An upgrade isn't complete until the regenerated wrapper files are committed. The four are: `gradle/wrapper/gradle-wrapper.properties` (the `distributionUrl` pin), `gradle/wrapper/gradle-wrapper.jar` (the bootstrap downloader, refreshed by the second pass), and the `gradlew` / `gradlew.bat` launcher scripts. Commit them together in one commit (ideally alongside the deprecation fixes). The point is reproducibility: anyone who clones and runs `./gradlew` downloads and uses precisely the pinned version — no "works on my machine" drift from locally installed Gradle. CI gets the same parity for free. If you commit only `gradle-wrapper.properties` but ship the old jar/scripts, you have a mismatch; if you forget the jar entirely, the wrapper can't bootstrap. Many teams also verify the distribution via `distributionSha256Sum` so a tampered download is rejected.

code

properties · 6 lines
properties
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip
distributionSha256Sum=544c35d6bd849ae8a5ed0bcea39ba677dc40f49df7d1835561582da2009b961d
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

go deeper

for a junior

List the wrapper files and know they go into git so others don't install Gradle.

for a middle

Explain reproducibility/CI parity and the consequences of stale or missing files.

for a senior

Add supply-chain concerns: distributionSha256Sum, mirror policy, and ensuring CI uses the wrapper not a system Gradle.

for a principal

Mandate checksum-pinned distributions and wrapper-only builds org-wide; address gitignore pitfalls and audit of the committed jar.

## The four files and what each does | File | Role | |------|------| | `gradle/wrapper/gradle-wrapper.properties` | Declares the version via `distributionUrl` (and optional `distributionSha256Sum`). | | `gradle/wrapper/gradle-wrapper.jar` | The bootstrap jar that reads the properties, downloads + caches the distribution, and delegates. | | `gradlew` | POSIX launcher script. | | `gradlew.bat` | Windows launcher script. | The second upgrade pass regenerates the jar and scripts so they match the new version. All four belong in version control. ## Why commit them — reproducibility and parity The whole value proposition of the wrapper is that the **repo carries its own build tool**. A fresh clone + `./gradlew build` works identically on a teammate's laptop, on a new hire's machine, and on CI — all pulling the exact pinned version. If wrapper files are missing or stale: - A missing jar means `./gradlew` can't bootstrap at all. - A stale jar/scripts against a new `distributionUrl` is an inconsistent state that can confuse tooling. - Relying on a locally-installed `gradle` reintroduces version drift and "works on my machine" bugs. ## Integrity: pin a checksum For supply-chain safety, add the distribution checksum: ```properties distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip distributionSha256Sum=544c35d6bd849ae8a5ed0bcea39ba677dc40f49df7d1835561582da2009b961d ``` Now the wrapper refuses to run if the downloaded zip doesn't match — protecting against a compromised mirror. `--gradle-distribution-sha256-sum` can be passed to the `wrapper` task to capture it. ## .gitignore caution Don't let `*.jar` ignore rules accidentally exclude `gradle-wrapper.jar`; it's one jar you explicitly *want* in the repo.

  • What problem does `distributionSha256Sum` solve?
    It verifies the downloaded distribution against a known hash, so a tampered or corrupted zip from a compromised mirror is rejected before it runs — a supply-chain safeguard.
  • Why is the wrapper jar a jar you deliberately keep in version control?
    It's the bootstrap downloader; without it `./gradlew` can't fetch the distribution. Blanket `*.jar` ignore rules must not exclude it.

saying these in an interview costs you the question

  • Saying only `gradle-wrapper.properties` needs committing.
  • Treating the wrapper jar as a build output that shouldn't be in VCS.
  • Ignoring distribution integrity/checksum entirely for a security-conscious shop.

context

resolving links…