build.gradle: update Gradle version to match gradle-wrapper.properties

[stephengold]

After PR #2197 (updating the Gradle version in gradle/wrapper/gradle-wrapper.properties) was integrated, @llzen44 pointed out that a Gradle version is also coded in the project's top-level build script.

I'm not 100% certain, but I assume this code is in case someone executes a "gradlew wrapper" command without specifying the desired version.

For the sake of consistency, this PR updates the top-level build script to specify the same version as gradle/wrapper/gradle-wrapper.properties

[tonihele]

This is the correct way of upgrading the wrapper, #2197 was not the correct way. Sorry I did not spot it.

1. Change the Gradle wrapper version of build.gradle
2. Run Gradle wrapper (gradlew wrapper in Windows)
3. Repeat step 2

[stephengold]

@tonihele: Thanks for that information.

Is our Gradle upgrade procedure documented somewhere other than this PR conversation?

I believe the JMonkeyEngine project is unusual in having its Gradle version hard-coded in "build.gradle".

The standard upgrade procedure in the Gradle release notes is simply ./gradlew wrapper --gradle-version=7.6.4

Perhaps we should simplify and standardize our Gradle upgrade process and code the version in just one place.

[tonihele]

@tonihele: Thanks for that information.

Is our Gradle upgrade procedure documented somewhere other than this PR conversation?

I believe the JMonkeyEngine project is unusual in having its Gradle version hard-coded in "build.gradle".

The standard upgrade procedure in the Gradle release notes is simply ./gradlew wrapper --gradle-version=7.6.4

Perhaps we should simplify and standardize our Gradle upgrade process and code the version in just one place.

Yes you can do that, and should if you feel that that is the correct procedure. The reason I've been doing it this way I described is that me and command line do not mix. I mostly use IDEs. That is probably why I have this habit.

So you can completely remove the wrapper task override from the build.gradle.

[stephengold]

I use the command line for many tasks, but I also wish to support people who use IDEs. I'm unsure how to proceed.

[tonihele]

I would just go with what is more standard. And I think it is your way. At least I got that impression from Gradle release notes you referred and all the guides I googled. The less we have our own custom standards and the more we comply to generally accepted standards, the better.

IDEs, like Netbeans, does allow giving arguments to Gradle tasks. Probably other IDEs as well, it is just not usually so convenient. Hidden behind some dialogs.