@StefMa Thanks for submitting this PR. I think this touches on some of #6137, but I think there are a few things tied up there:

1. You can pass any version, even for versions that don't exist.
2. You can pass any URL, even for URLs that are invalid.
3. There's no validation when running gradle wrapper that the build is in a "good" state anymore.
4. When you're not in a good state, the build fails with a cryptic message and going back to a good state is a manual step outside of Gradle.

For 3), one thing we've thought about in the past was to make sure the gradlew scripts and wrapper jar were from the target distribution. If we did this, I think we'd get the validation for "free" since we'd need to download the distribution during the update. This is a bigger change and would need some thinking.

For 4), one simple thing we could do is improve the error messages when Gradle can't download a distribution. Instead of just getting a big ugly stacktrace, we could show something more human readable. This could help other situations where someone manually changes the gradle-wrapper.properties file.

IMO, this is a low priority annoyance. When I do wrapper upgrades, I just do this out of habit now:
./gradlew wrapper --gradle-version=someVersion && ./gradlew wrapper

1. I know I have the right version of the jar and scripts
2. I know the distribution can be downloaded
3. I know the build still loads with the new distribution

There are questions in my mind about how much other validation should be done (checking full URLs, configuring the build with the new distribution, trying to download the distribution, etc) and maybe it would be worth spending time on something else (better errors, making it easier to upgrade so you're not dealing with versions at all).

I think the easiest way to test something like this would be to try to select a version that we know doesn't exist (e.g., 1.2.3) or running a HTTP server that doesn't serve the distribution we look for (there are some tests that do this already).

Hey @big-guy thanks for the comment 👍
There is really a lot to think about 🤯.

From my point of view - and as a Gradle user - the most used argument is --gradle-version only (and maybe the --distribution-type). What I want to say is that I think we shouldn't care about the gradle-distribution-url argument because this is something what only "expierenced" Gradle users do. And I think they do it with care (know that the URL is reachable). That is also the reason why I only added the check to the "gradle-version case".
But of course - adding a check for these cases make also sense. But with low priority.

maybe it would be worth spending time on something else (better errors, making it easier to upgrade so you're not dealing with versions at all).

When I read this I think about to change the wrapper task (running with no arguments) to something like the init task. Where we get a selection of all available Gradle versions and the user can pick the one he want to use.
I know there is somewhere at gradle.org a json with all the available version. Maybe we could parse these and display the versions...
What do you think about this solution?
Would be a great solution especially for beginners. Who don't know which versions are available...
Could you please give me a link to the URL? That would be great :)

@StefMa, see http://services.gradle.org/, especially "Version Information"

@StefMa I've just come back around to this PR. I'm trying to work off the backlog of community PRs and respond a bit quicker than we have before.

This is what I think we should do to make Gradle a little bit better:

1. As part of Wrapper.generate(), check if the URL is reachable. If it's not, fail the task with a useful message.
   • Add an integration test to WrapperGenerationIntegrationTest that passes an unreachable URL as the distribution URL (e.g., http://always.invalid`) and check that the build fails with a useful message and does not modify any other files. "generated wrapper scripts for given distribution URL from command-line" is a good place to start.
2. As part of Download.downloadInternal(), make the message for an invalid distribution URL nicer.
   • Add an integration test to WrapperUpgradeIntegrationTest that generates a working project and then modifies the gradle-wrapper.properties to a "bad" URL and tries to use it. Verify that the nicer message is produced.

Please keep in mind that the distribution URL doesn't necessarily mean HTTP. It could be a file://

How does that sound? Thanks for your help in advance.

I'm going to close this PR for now. Please feel free to submit a new one based on my comment above