This message was deleted.

When you say wrapper you probably mean the Gradle version of the build? Because that has nothing to do with the wrapper. The wrapper are just the 4 files your check in. In one of them, the properties file, the Gradle version for the build is defined that is downloaded and executed by the wrapper. So assuming you mean the Gradle version, usually a good tactic is to update the plugins to latest version, so that chances are higher it is compatible with newer Gradle, then update to latest minor version within the same major version, fix all deprecation warnings, upgrade to the next major version and so on until you are on latest. And in the way consider the upgrade notes in the user guide, not only the release notes which for example do not mention breaking changes. This usually makes a smooth processes.

As a Gradle newbie who has inherited an existing code base that is a Big Ball Of Mud, I appreciate your attempts to educate me... Is this the right way to define the Gradle version?

task wrapper(type: Wrapper) {
   gradleVersion = '7.5.1'
}

I just looked that up on https://stackoverflow.com/questions/22778139/how-to-define-gradle-version-to-use-inside-build-gradle. Is there a better way to do this? Up until now, I thought we had to upgrade the wrapper itself with

gradle wrapper

which upgrades the local wrapper to the same version as the installed Gradle. This is actually problematic...

Well, no, that setting imho is pretty useless. Besides that you try to create a new task called

wrapper

instead of configuring the existing one. And besides the face that you do not leverage task configuration avoidance (I recommend you read the doc chapter about it, out of scope here). It is correct that the

wrapper

task or the 4 wrapper files in place, taken from the currently running Gradle version. So if you want to update Gradle to 7.5.1 and also the wrapper files to the latest version, you would run

./gradlew wrapper --gradle-version 7.5.1 --gradle-distribution-sha256-sum f6b8596b10cce501591e92f229816aa4046424f3b24d771751b06779d58c8ec4

twice. First to update the Gradle version and then again to update the wrapper files from that new version.

How is that different than

gradle wrapper

When this succeeds, if I do

./gradlew --version

it reports back as 7.5.1 I only use the local gradle to upgrade the wrapper...

As I said, if

gradle

runs a 7.5.1 the only difference is that you do not have the sha256 checksum set. Maybe your misunderstanding is, that

./gradlew --version

does not give you the version of the wrapper. The wrapper does not have a displayable version. That command gives you the version of the Gradle version running as that is what is relevant for the build. The wrapper is just for downloading the necessary Gradle version if necessary, verifying its sha256 sum if you have set it and running it to execute the build.

I am still confused... if I do

./gradlew --version

, it reports an old version... After I do

gradle wrapper

and it succeeds, if I do

./gradlew --version

it reports the latest version...

So? What confused you with that?

Maybe your misunderstanding is, that

./gradlew --version

does not give you the version of the wrapper.

So, why the change in version reported?

The

wrapper

task writes the four wrapper files.

gradlew

,

gradlew.bat

, and

gradle/wrapper/gradle-wrapper.jar

from the currently running version of Gradle.

gradle/wrapper/gradle-wrapper.properties

with content that among other things contains the Gradle version used to run the build if the wrapper is used. The default version for that value is also the currently running version of Gradle, but can be overwritten using config in the build script (does not make much sense) or commandline parameter. So assuming you have there 7.1, then

./gradlew --version

will report 7.1. If you then do

gradle wrapper

where

gradle

runs a 7.5.1, the wrapper files are updated with the new version and from 7.5.1, so

./gradlew --version

report 7.5.1 and the wrapper is latest version. If

gradle

runs a Gradle version 6.5 but you have the config in the build script you showed that configures version to 7.5.1, then the wrapper files written will be from version 6.5 but the version in

gradle-wrapper.properties

will be 7.5.1, so

./gradlew --version

will also show 7.5.1. If you have still 7.1 in the

gradle-wrapper.properties

, and then do

./gradlew wrapper --gradle-version 7.5.1 --gradle-distribution-sha256 ...

, the wrapper files written will be from 7.1, but the version in

gradle-wrapper.properties

will be 7.5.1, if you then execute it a second time, the wrapper files written will also be from 7.5.1 as now 7.5.1 is the version used to execute the build.

I already understood most of what you said, but you have not told me what I was doing wrong...

I didn't way you did something wrong. I just said you should create a new wrapper task but configure, the existing one, that it does not make much sense to configure the Gradle version in the build script, and that you should always use the Wrapper and not some installed Gradle version. Instead just define the target Gradle version on the commandline and call the task twice using the wrapper.

I don't configure the Gradle version in the gradle.build file. I was asking if I should, based on StackOverflow advice... I always use the wrapper... I only use the local

gradle

to upgrade the wrapper... Sorry, the process you describe is way too complex... it may be more robust, but I try to avoid unnecessary cognitive load...

Not overly complex:

./gradlew wrapper --gradle-version 7.5.1
./gradlew wrapper

I was talking about all that

sha256

stuff... I will try your method next time I do and upgrade, to see if it solves other problems I am having...

I don't configure the Gradle version in the gradle.build file. I was asking if I should, based on StackOverflow advice...

SO is full of bad advice. 😄

I always use the wrapper...

👌

I only use the local

gradle

to upgrade the wrapper...

So not always, but why? Just use the wrapper as I suggested

Sorry, the process you describe is way too complex

It is too complex to execute two simple commands? o_O

the published sha256 sums are available here.

Yes, I already told him this above 🙂

At this point, I don't care about safety... I just want to stop fighting with our Big Ball Of Mud... 😱 Later, when I am less traumatized, and I document processes for others, I will visit improved safety...

Best of luck with the Mud-Fest; we’ve all been there…

Well, your decision, doesn't really make it more complex imho and is a very low hanging fruit improving safety. But of course fully your decision. 🙂

Right now... my personal sanity is my highest value...

Don't forget to put on the cow gloves 🙂

And big rubber boots

And I do not mean these:

🤣