Custom GradleWrapper - #16483
Conversation
Execute gradle in the same JVM. Support the gradle-wrapper.jar if present. Only include basic/used gradle-wrapper.properties
dweiss
left a comment
dweiss
left a comment
There was a problem hiding this comment.
I like the idea. I'm not sure what the original gradle wrapper does (or will do in the future) though - it'd be good to move the burden of maintaining it to gradle itself... but I don't have high hopes they'll be interested.
What was the source of your frustration with the previous downloader? It didn't work? I never had any problem with it, even when switching branches etc.
| @rem No staleness check: if you edit GradleWrapper.java, delete %GRADLE_WRAPPER_CACHE% to force | ||
| @rem a recompile (this file changes rarely, so keeping this simple is worth that manual step). |
There was a problem hiding this comment.
It's going to be trouble on Windows if the wrapper is updated.
There was a problem hiding this comment.
There seem to be some powershell solutions to check the 'if newer' condition but they're rather hairy. Don't know if there's any other way but right now I think it's going to be trappy for WIndows users.
| throw new IOException("Wrapper property file not found: " + wrapperProperties); | ||
| } | ||
|
|
||
| Pattern versionPattern = Pattern.compile("gradle-(?<version>.+?)-bin.zip"); |
There was a problem hiding this comment.
What was the source of your frustration with the previous downloader? It didn't work? I never had any problem with it, even when switching branches etc.
Our downloader's regexp didn't like my corporate URL to our local gradle location. The "." in there could match anything, even a forward slash.
But even fixing that didn't resolve the matter since my corporate env can't access internet sites like 'raw.githubusercontent.com`. Ugh! So in a fit of frustration, I went on this path. Downloading a downloader is insanity. Just download the final thing already!
There was a problem hiding this comment.
So it can download gradle but can't download the wrapper? Maybe we could just modify the location the wrapper is downloaded from so that it's the same as gradle distribution?
I don't oppose the change but it breaks Windows, for example - the up-to-date check there is gone and switching between different versions won't work.
| # Ignore gradle wrapper jar. | ||
| gradle/wrapper/gradle-wrapper.jar | ||
|
|
There was a problem hiding this comment.
This is removed from gitignore yet the batch scripts clearly seem to support the presence of gradle wrapper (?). I also wonder how IDEs are going to react to the missing wrapper file...
| // Doesn't need to match Gradle's own MD5-based cache hash scheme (PathAssembler) -- this is | ||
| // an independent cache, keyed only well enough to dedupe by exact distributionUrl. | ||
| String hash = sha256Hex(urlStr).substring(0, 16); | ||
| Path installRoot = | ||
| gradleUserHome.resolve("wrapper").resolve("dists").resolve(baseName).resolve(hash); |
There was a problem hiding this comment.
There is a global lock in the original wrapper here and it's for a reason - if somebody starts multiple builds in parallel it can potentially leave an inconsistent state of a global "cached" install. I'm also not sure we can reuse the same directory as the official distribution... not sure what they do to these files/ directories. Maybe it'd be good not to interfere?
2 participants
I got frustrated with the gradle wrapper situation. The fact that we went through all this trouble here with a custom downloader -- all to download another tiny program (the actual gradle wrapper) to basically just download and run Gradle ... seems a bit silly, no?
So I had an idea and filed it with the Gradle project to offer the wrapper in source form.. Maybe they won't implement the idea but nonetheless we are certainly empowered to do so. It's not hard!