Upgrade to Gradle 6.7.1

[karivatj]

Hello,

I've been working on refactoring the android-gpgs implementation because it uses deprecated Google APIs. However, when building the project I noticed that the project is based on an older Gradle version. I figured I'd migrate the project to Gradle 7.0.3 before proceeding with the actual refactoring.

Here is a PR that contains the needed changes to build / deploy the project with Gradle 7. Basically all of the gradle scripts needed some tuning to get this to work.

Building with gradlew clean publishToMavenLocal on Windows or gradle clean publishToMavenLocal on Linux works great and the local repository populates with libraries I can use in my project.

Obviously I haven't tested deploying the package to the external repository but thats something maybe you, the developer, can test.

If you need me to do any additional fixes or other changes please let me know.

[MrStahlfelge]

Hi, please repair the GitHub actoins build.

There are some changes that seem unnecessary (renaming minSdk, targetSdk etc. to *Ver) and cause changes that could be avoided.

Setting ios and core modules to Java version 8 is dangerous until all platforms supported support Java 8. While RoboVM can handle some Java 8 language features, it is still better to keep the source level on 7 so problems get caught on compile time, not on runtime.

Are you sure Gradle 7 is needed? For most things, Gradle 6.7 is still a viable alternative which causes much less problems in terms of backwards compatibility.

[karivatj]

Hi,

Thanks for the comments. I will take a look at the issues you raised and will update the PR accordingly.

Br. Kari

[karivatj]

Hello,

I looked into the issues you mentioned and here are some thoughts:

There are some changes that seem unnecessary (renaming minSdk, targetSdk etc. to *Ver) and cause changes that could be avoided.

I will go through the changes and remove any unnecessary changes. However, with the new Gradle 7 the compileSdk, targetSdkand minSdk are reserved keywords and thus cannot be used. That is why we need to use a different name for the variables.

Setting ios and core modules to Java version 8 is dangerous until all platforms supported support Java 8. While RoboVM can handle some Java 8 language features, it is still better to keep the source level on 7 so problems get caught on compile time, not on runtime.

Fair enough I will revert back to Java 7. I was refactoring the gpgs-client and decided to use lambdas which are supported in Java 8. I will revert the changes.

Are you sure Gradle 7 is needed? For most things, Gradle 6.7 is still a viable alternative which causes much less problems in terms of backwards compatibility.

I made some investigation and couldn't find any source that declares one shouldn't use Gradle 7. As far as I know Gradle 7 is the latest stable version and incorporates many improvements and bugfixes over Gradle 6. What is your preference? Should we stick to Gradle 7 or should I downgrade to Gradle 6?

[karivatj]

Reverted to Java 7 and made a slight change to compile.yml

Had to change:

run: ./gradlew clean uploadArchives -PSNAPSHOT=true -PLOCAL=true

to

run: ./gradlew clean publishToMavenLocal -PSNAPSHOT=true -PLOCAL=true

publishToMavenLocal copies all defined publications to the local Maven cache, including their metadata (POM files, etc.).

When publishing a release version one should use

run: ./gradlew clean publish -PRELEASE=true

[MrStahlfelge]

Gradle 7 needs Java 11, so not useable on environments still running jdk 8. That's why 6.7 is widely used at the moment. I would prefer to use it if it works with the latest dependencies.

[karivatj]

Hi,

Understood. I downgraded Gradle to 6.7.1 and com.android.tools.build:gradle module to version 4.2.2 which supports Gradle 6.7.1+.

Builds fine with ./gradlew clean publishToMavenLocal -PSNAPSHOT=true -PLOCAL=true

[karivatj]

Updated the PR.

• Libgdx back to 1.9.8.
• Moved dependencies to submodules where they are used.
• Added some comments to the question about publishing the artifacts.