Upgrade Gradle 4.10 -> 5.6.4 - #1238

@tonihele thank you! Is it possible to jump up to 6.0? or does that break things?

I'd been dreading this transition, so thank you for making it happen. By the way, all my other projects are on Gradle v6.0.1.

I didn't try the version 6. I'm little bit conservative with these. And I thought you were too :)

Anyway, the Gradle wrapper has been set up. So to upgrade, all you need to do is to change the version number in the build.gradle. Execute "gradlew wrapper" twice and that is it.

Hmm, is this my fault? The Android native building didn't work. Is it the Android Gradle tools? The documentation does give the impression that it should work with this newer version although not recommended.

The logs show:
BUILD SUCCESSFUL in 6m 26s
43 actionable tasks: 43 executed
##[error]The operation was canceled.

Also what about this:
Run gradle -PuseCommitHashAsVersionName=true --no-daemon -PbuildNativeProjects=true
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.5/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing

Hmm, is this my fault?

Based on my experience with TravisCI, I suggest restarting the continuous integration for that commit.

How? I can't find the button :(

Click on "Details" and the button is labelled "Re-run checks".

Hmm, maybe a access right or wooden eye thing...? Can you post a screenshot?

It seems that continuous integration isn't using the Gradle wrapper. For the runs I looked at, it used Gradle 6.0.1. For instance:
https://github.com/jMonkeyEngine/jmonkeyengine/pull/1238/checks?check_run_id=366914118#step:4:29
https://github.com/jMonkeyEngine/jmonkeyengine/pull/1238/checks?check_run_id=366914110#step:4:28

Also, I see the CI building native libraries, but no JARs or merged Javadoc. Have you tested those cases?

Regarding the re-run: I'll push the button myself.

Also, I see the CI building native libraries, but no JARs or merged Javadoc. Have you tested those cases?

I tried build & run. Both work. They do the JARs and javadoc if I understood correctly.

Merged javadoc is a separate task:
./gradlew mergedJavadoc

It doesn't get run very often, so it might've been partly broken before.

It reports success at least, the task.
I don't know if it is a good thing that the checks run their own version of Gradle. Or is it always that environment when you release? Or how does it work?

I haven't studied the new build/CI process. Presumably @riccardobl understands it.

The merged javadoc is built everytime and stored in the 'javadoc' artifact ( https://github.com/jMonkeyEngine/jmonkeyengine/suites/377632524/artifacts/886452 ).

It is true that the CI runs the gradle version that is installed in the build environment (also for releases), but we can change it to use gradlew if you guys want that. It might be slightly slower, but shouldn't be noticeable.

I am not sure if setting "-Xmx64m" "-Xms64m" is a good idea.

This comes automatically with the update. Only manual addition is the wrapper task in the build.gradle. I guess you can still of course modify the "generated" code if you really want to.

re: "It is true that the CI runs the gradle version that is installed in the build environment (also for releases),"
Historically, we've had to carefully tailor our gradle version to work properly... to the point that we recommend that users ALWAYS run gradlew to compile JME. (I certainly always do.) The CI process should be using the same version we do... ie: the gradle wrapper version.

...otherwise we could spend lifetimes tracking down odd build problems that work fine locally and only fail in CI.

The version was in sync with the gradlew, but now that we update it, we can move to gradlew.
It'll take a bit more to bootstrap in every job, since it has to download gradle, but we can live with that.

All you need to do is replace gradle commands to ./gradlew in the CI script.
Can you do that in this pr @tonihele ? If not i'll make one later.

All you need to do is replace gradle commands to ./gradlew in the CI script.
Can you do that in this pr @tonihele ? If not i'll make one later.

I can try tomorrow.

CI updated. Seems to work.

Seems that the last time you upgraded the Gradle, you also updated the Android tools version. As I mentioned, I was too scared to do that since I don't know what they do and how to test. But seems that is highly recommended. So maybe someone could take a look at those.

And now there's a Gradle v6.1.

They have actually very frequent releases, hard to keep up. Do you want me to update to that version? Or another PR after this to go further in Gradle + those Android tools to further let somebody test them?

Basically this PR adds the tech to do it easily now on as well as have the CIs use the version provided. And should be quite risk free.

Some script modifications are needed to build JME using Gradle 6 without warnings. Currently I get:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.1/userguide/command_line_interface.html#sec:command_line_warnings

Unless you're willing to work around the deprecated features, I'd rather you didn't upgrade JME past Gradle 5.6.4 .