Gradle WrapperDownloader: move URL & sha into properties by dsmiley · Pull Request #16521 · apache/lucene

dsmiley · 2026-08-18T23:07:37Z

And don't bother checking if the wrapper jar is out-of-date.

Goal: (1) Allow configuration of the wrapper location. (2) simpler; easier to maintain

Can replace #16483

And don't bother checking if the wrapper jar is out-of-date.

dsmiley · 2026-08-18T23:12:09Z

I prefer not validating that an existing gradle wrapper matches the sha. Why bother checking this? If the user has a wrapper (whatever version/origin) that continues to work for them, let them continue to use it. If they don't like it anymore, they are free to remove/replace it.

Admittedly I was primarily motivated by the simplicity of using gradle-wrapper.properties for everything the downloader and the wrapper itself needs to know..

The sha checking code is there because if you're switching branches (for example, the wrapper version changes), you want to update the wrapper jar too. It is a stricter check than just file timestamps.

dsmiley · 2026-08-18T23:13:21Z

      throw new IOException("Wrapper property file not found: " + wrapperProperties);
    }

-    Pattern versionPattern = Pattern.compile("gradle-(?<version>.+?)-bin.zip");


note: this pattern was flawed because the . can match a \

Hmm.... What do you mean? It doesn't have a DOTALL flag, it should work just fine?

The regexp is used with matcher.find(), which returns the LEFTMOST match. The non-greedy
.+? doesn't save you here, because . also matches / -- so the capture happily runs across path separators.

I know what it does but I can't see how you're hitting a problem here - I suspect you're modifying this in place:

distributionUrl=https\://services.gradle.org/distributions/gradle-9.7.0-bin.zip

and your corporate url doesn't match the pattern, right? Sorry for being dim. Can you give me an example of when this pattern fails to work?

Anyway, this isn't a solution in the long term because this file is versioned... It'll be a nightmare for you to have to adjust it everywhere.

I've gone through gradle's docs, issues and the wrapper code and I wonder how anybody in a corporate environment is solving the problem of auto-gradle-distro-installation (wrapper jar aside). There seem to be only two options that I see:

use http proxy props and a proxy server to redirect gradle's "official" URLs to another location; this is tricky with https certs,

store the binary distribution with the code (yes, it's possible). This dodges the download problem entirely.

It's interesting to me that there seems to be no way of redirecting these URLs "dynamically" -- seems like people behind firewalls need to install gradle manually (?). I guess adding a property to download something from arbitrary locations may be perceived as a security issue, don't know.

Looking at what's inside the gradle wrapper code, we may indeed try to simulate the same runtime behavior (using much less code) but skipping gradle-wrapper.jar entirely will break higher-level tools that depend on it (like intellij) so I think it needs to be there.

dsmiley · 2026-08-18T23:14:05Z

+# Read by Lucene's WrapperDownloader (not by the actual wrapper) to bootstrap gradle-wrapper.jar.
+wrapperSha256=497c8c2a7e5031f6aa847f88104aa80a93532ec32ee17bdb8d1d2f67a194a9c7
+wrapperUrl=https\://raw.githubusercontent.com/gradle/gradle/v9.6.1/gradle/wrapper/gradle-wrapper.jar
+#   To self download, try %> curl -Lo gradle/wrapper/gradle-wrapper.jar <wrapperUrl>  (from the repo root)


this comment is helpful to anyone who wants to download it themselves (me). I have proxy env vars.

I wouldn't put anything in here. This is controlled by gradle - when you update the wrapper, it'll likely get overwritten and people use llms more and more for such stuff... Likely to break in my opinion.

dweiss

I am not convinced this is a good change, I tried to add my comments where they're relevant. In short: I wouldn't piggyback our own stuff in gradle.properties and I think the sha checksum makes sense here to ensure consistency when switching branches back and forth between versions.

dweiss · 2026-08-19T18:38:45Z

      throw new IOException("Wrapper property file not found: " + wrapperProperties);
    }

-    Pattern versionPattern = Pattern.compile("gradle-(?<version>.+?)-bin.zip");


Hmm.... What do you mean? It doesn't have a DOTALL flag, it should work just fine?

dweiss · 2026-08-19T18:40:59Z

+# Read by Lucene's WrapperDownloader (not by the actual wrapper) to bootstrap gradle-wrapper.jar.
+wrapperSha256=497c8c2a7e5031f6aa847f88104aa80a93532ec32ee17bdb8d1d2f67a194a9c7
+wrapperUrl=https\://raw.githubusercontent.com/gradle/gradle/v9.6.1/gradle/wrapper/gradle-wrapper.jar
+#   To self download, try %> curl -Lo gradle/wrapper/gradle-wrapper.jar <wrapperUrl>  (from the repo root)


I wouldn't put anything in here. This is controlled by gradle - when you update the wrapper, it'll likely get overwritten and people use llms more and more for such stuff... Likely to break in my opinion.

dweiss · 2026-08-19T18:42:31Z

The sha checking code is there because if you're switching branches (for example, the wrapper version changes), you want to update the wrapper jar too. It is a stricter check than just file timestamps.

dweiss · 2026-08-19T18:49:34Z

Would it be sufficient for your corporate environment if:

we modified the regexp to be more strict and match version number only.
perhaps allow passing gradle wrapper "location template" via environment variable, for example?

dsmiley · 2026-08-19T20:52:21Z

A "location template" sounds more complicated than needed. Why not simply provide the wrapper location (URL) itself?

dsmiley · 2026-08-20T13:05:37Z

we don't need to change the gradle wrapper any more often than we move to a major version, and even that is unnecessary.

dweiss · 2026-08-20T16:17:08Z

we don't need to change the gradle wrapper any more often than we move to a major version, and even that is unnecessary.

True. But this doesn't solve the problem of hardcoded gradle distribution URL - this is in wrapper.properties and it's a versioned file (see my other comment).

dweiss · 2026-08-20T21:58:02Z

I've done some experiments with replicating what gradle-wrapper does (like you did, David) and I think it's a better way to go - have a custom class to download and install a gradle distribution. It's really not that much code and it's self-contained. Give me some time to test it out though and perhaps polish machine-generated experiments.

dweiss · 2026-08-21T07:20:08Z

Here is my take on this: #16543

Gradle WrapperDownloader: move URL & sha into properties

6b86907

And don't bother checking if the wrapper jar is out-of-date.

dsmiley requested a review from dweiss August 18, 2026 23:07

github-actions Bot added the module:build-infra label Aug 18, 2026

dsmiley commented Aug 18, 2026

View reviewed changes

UTF8 properties

21f1588

dweiss reviewed Aug 19, 2026

View reviewed changes

dweiss mentioned this pull request Aug 21, 2026

Add custom URL patterns for downloading gradle distribution and gradle wrapper #16543

Open

Uh oh!

Conversation

dsmiley commented Aug 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dweiss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dweiss commented Aug 19, 2026

Uh oh!

dsmiley commented Aug 19, 2026

Uh oh!

dsmiley commented Aug 20, 2026

Uh oh!

dweiss commented Aug 20, 2026

Uh oh!

dweiss commented Aug 20, 2026

Uh oh!

dweiss commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants