I am supporting an open source project that is contributed to by enterprise users who can't download the gradle wrapper through the public URL, but must use a custom

distributionUrl

. I'm wondering if its possible for these users to override the

distributionUrl

without setting it in the

gradle-wrapper.properties

file since they would break the public build if they accidentally checked in their enterprise URL.

Would it be workable for them to just ensure the wrapper is already present? Maybe put there by a separate "bootstrapping" build that is only there to get the distribution from the other URL?

you could also ask your developers to add a line in

.git/info/exclude

for this project, or provide them a

pre-commit

git hook script to install in

.git/hooks

, though this is more about git than gradle (you could also automate or enforce this with gradle eventually)

An exclude is useless. You cannot exclude an already versioned file.

If the wrapper already exists, then running

./gradlew

shouldn't try and reach out to the public distribution url, is that correct?

Iirc, yes. That's why I suggested to just make sure it is present if possible

Thanks I'll give it a try

then running ./gradlew shouldn't try and reach out to the public distribution url, is that correct?

as long as a distribution with the exact same download URI was already downloaded apparently, having the same version is not enough so your team may still run into issues if they never used a wrapper to download this version of Gradle from the public

<https://services.gradle.org/distributions/gradle->...

E.g. a wrapper-downloaded Gradle 8.8 will end up in

~/.gradle/wrapper/dists/gradle-8.8-bin/dl7vupf4psengwqhwktix4v1/gradle-8.8/

, where

dl7...

is a hash of the download URI. As @Vampire pointed out you can't use

.gitignore

or

.git/info/exclude

to ignore modifications to a file that was checked out, and using

git update-index

doesn't sound like a good idea in this context. You could eventually hack something with gitattributes and a filter, but IMO the best way to deal with this if pre-downloading the public distribution is not possible would be to tell your team not to use the wrapper for this project and use instead a local installation of your private distribution of Gradle.

Oh, the hash is of the download url? o_O

yes, or copying the whole tree of your private distribution to the hash of the public URI would probably work here

That's what I meant with "rename". Of course "copy" might be more appropriate here as they probably need both, yeah. 🙂

Thanks, this makes sense... it really would be nice if you could run the wrapper and pass in the distributionUrl as a Java property or environment variable (the latter is probably better)

It wouldn't help if you could

Darn chicken and egg problems