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

jMonkeyEngine / jmonkeyengine

A complete 3-D game development suite written in Java.

http://jmonkeyengine.org

BSD 3-Clause "New" or "Revised" License

3.8k stars 1.12k forks source link

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

Closed stephengold closed 7 months ago

stephengold commented 7 months ago

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 commented 7 months ago

This is the correct way of upgrading the wrapper, https://github.com/jMonkeyEngine/jmonkeyengine/pull/2197 was not the correct way. Sorry I did not spot it.

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

stephengold commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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.