Could this be a good candidate to modularize and pull the latest wrapper generation module if connected to the internet? If not, then we can use the current version in the distribution. This would enable for every version going forward to benefit with the latest code generation code. The downside is it would be more work to implement at this stage.

@eriwen How much work it is? Can we fit it into 3.3 to reduce the impact of 3.2.1 wrapper bug?

@pioterj I suspect not so much work that we can't get it in for 3.3. We will prioritize it highly in our sprint planning Monday.

Actually is that issue really a solution to avoid impact of 3.2.1 wrapper bug? What if a user just upgrade gradle version manually in wrapper.properties?

I think we should deprecate editing the wrapper properties directly, and move towards the user always using the wrapper generation logic directly or indirectly, so that we can do whatever upgrades, validation and optimisations make sense for the delta from old version to new version. And so we can move the responsibility for determining which Gradle runtime version to use, and where to get it from, and which parts are required, out of a properties file and into build logic.

Sounds good in the long term, @adammurdoch.

What do we do for 3.3 though? Can we for instance give a meaningful error message for users running into GRADLE-3582 or GRADLE-3583 asking them to regenerate the wrapper files by detecting that they were generated by 3.2?

Given our current priorities and timeline, I'm de-prioritizing this for now.

In Gradle 4.7, this issue is still present. I have to call the update task twice every time a new Gradle version is released.

I've not been able to spot a nice solution to this with the current packaging - they all seem to necessitate weird nested/multiple executions if you want gradle-wrapper.jar and gradlew, gradlew.bat scripts to be from the new/next Gradle runtime version. This because the distribution download logic lives in the wrapper runtime, whereas the Wrapper task lives in the build itself, which is already running (possibly for the last time for this project) with the older Gradle runtime.

Unless:

• a) The matching, or latest, or separately-versioned gradle-wrapper.jar were available for separate download, OR
• b) Wrapper task itself forces a (next) runtime install as if a do-nothing build were run as part of the task, post properties-file update. Significant behaviour change. Also hard to pull the wrapper jar from the dist since it's not yet on the classpath. OR
• c) The wrapper itself becomes aware of the wrapper task (not ideal?) and partitions it into two executions, one which triggers the properties-file update, the second which will force a download/install and take the JAR and make the scripts from that. Or it could detect changes to the wrapper config during the build and do same. Messy.

Curious what the current thinking is, or whether this is headed for a can't-fix under that current wrapper architecture.

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

Particularly while #12273 has not been addressed, I think this should remain open. Unless you know to run wrapper twice, it's a bit too easy at the moment to end up with scripts from an older version of Gradle.

I was about to file an issue that the wrapper task needs to be run twice after updating its configuration, but it appears that might be the same as this issue. Let me know otherwise if I should file this as a separate issue:

Steps to Reproduce

1. Update the Wrapper task configuration to a newer version of Gradle:

tasks {
    named<Wrapper>("wrapper") {
        gradleVersion = "7.5.1" // Was "7.5"
        distributionType = ALL
    }
}

2. Run gradlew wrapper.

Expected Behavior

The './gradle/wrapper/gradle-wrapper.properties', './gradle/wrapper/gradle-wrapper.jar', './gradlew', and './gradlew.bat' files are all updated (as applicable) for the new version.

Current Behavior

Only the './gradle/wrapper/gradle-wrapper.properties' is updated with a new distributionUrl value for the new version. The wrapper task must be invoked a second time for the './gradle/wrapper/gradle-wrapper.jar', './gradlew', and './gradlew.bat' files to be updated (if applicable). This can lead to extra commits/PRs when these files are shared via version control, as the updater may not be aware of the need to run the task twice.

If this is not trivial to fix, perhaps logging a warning that the task needs to be run a second time would be helpful in the interim (though maybe it's nontrivial to identify the initial invocation after a gradleVersion configuration change).

I cannot believe this ticket is STILL open after more than 7 years from it being reported? Guys this is one of the most fundamental part of Gradle. Furthermore, it's listed on the Upgrade page:

People (including me) would expect this to work. I must always go after my colleges and verify if the wrapper upgrade was successful or not (because the jar might be outdated). So much wasted time!

Is there any ETA for this?