-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Gradle WrapperDownloader: move URL & sha into properties #16521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,3 +7,8 @@ retryBackOffMs=500 | |
| validateDistributionUrl=true | ||
| zipStoreBase=GRADLE_USER_HOME | ||
| zipStorePath=wrapper/dists | ||
|
|
||
| # 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) | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this comment is helpful to anyone who wants to download it themselves (me). I have proxy env vars.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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..
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: this pattern was flawed because the
.can match a\There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.... What do you mean? It doesn't have a DOTALL flag, it should work just fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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:
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.