THRIFT-5553: java library to use newer gradle API

[jimexist]

java library to use newer gradle API, fixing most deprecation warning generated by ./gradlew help --scan

• Did you create an Apache Jira ticket? (not required for trivial changes)
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[ctubbsii]

I don't know gradle, but I don't see anything particularly problematic in this PR.

[jimexist]

i'm not sure i can debug the CI failures - seems an issue with travis itself as the failures do not have logs and they occur randomly (same situation with other pull requests)

[ctubbsii]

i'm not sure i can debug the CI failures - seems an issue with travis itself as the failures do not have logs and they occur randomly (same situation with other pull requests)

I don't think those failures are related to this change, but I can't be sure. The individual tasks aren't well named and I'm not sure what they're doing.

Also, somebody familiar with the Travis CI configuration might want to investigate moving over to GitHub Actions, since 1) it's built-in to GitHub and possibly a bit more reliable/less dependencies on another party, and 2) I don't trust Travis CI's new permissions model that seems to require granting it oauth permissions for private repos in order to log in to Travis-CI.com to manage builds, even if you only want to use it with public repos. I wonder if that was partially the reason for this recent security incident involving Travis CI app being targeted and used as a mechanism to steal private repo contents

I know one of the main limits of GitHub Actions is the inability to use ARM or other non-x86 architectures when building. As a Java developer I don't generally care about that, but I'm guessing the Thrift project probably cares.

[jimexist]

i'm not sure i can debug the CI failures - seems an issue with travis itself as the failures do not have logs and they occur randomly (same situation with other pull requests)

I don't think those failures are related to this change, but I can't be sure. The individual tasks aren't well named and I'm not sure what they're doing.

Also, somebody familiar with the Travis CI configuration might want to investigate moving over to GitHub Actions, since 1) it's built-in to GitHub and possibly a bit more reliable/less dependencies on another party, and 2) I don't trust Travis CI's new permissions model that seems to require granting it oauth permissions for private repos in order to log in to Travis-CI.com to manage builds, even if you only want to use it with public repos. I wonder if that was partially the reason for this recent security incident involving Travis CI app being targeted and used as a mechanism to steal private repo contents

I know one of the main limits of GitHub Actions is the inability to use ARM or other non-x86 architectures when building. As a Java developer I don't generally care about that, but I'm guessing the Thrift project probably cares.

I agree with that GitHub Actions more user friendly and efficient. If that's a direction that the community wishes to move towards I'd be able to help.

[ctubbsii]

I agree with that GitHub Actions more user friendly and efficient. If that's a direction that the community wishes to move towards I'd be able to help.

That would be great. I think they could replace AppVeyor as well.

[jimexist]

I agree with that GitHub Actions more user friendly and efficient. If that's a direction that the community wishes to move towards I'd be able to help.

That would be great. I think they could replace AppVeyor as well.

Let me create https://issues.apache.org/jira/browse/THRIFT-5564 and wait for some more feedback if any.

[jimexist]

FYI i also had to update tutorial/js and tutorial/java since their ant build refers to the legacy java libs

[ctubbsii]

@jimexist I merged master into this one to bring it up to date. I ran a gradle build and it seems to work fine with Gradle 6.9.2. However, it still shows a warning that Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.

[jimexist]

However, it still shows a warning that Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.

yes because we still have one thing left: migrate maven plugin to maven-publish plugin. that's a bigger task to handle so i'll do it later, along with upgrading to gradle 7.x

[ctubbsii]

Looks fine to me. Will wait for CI. In the meantime, @jimexist , please make sure that there wasn't any errors introduced while resolving merge conflicts, and that this is still ready to go.

[jimexist]

Looks fine to me. Will wait for CI. In the meantime, @jimexist , please make sure that there wasn't any errors introduced while resolving merge conflicts, and that this is still ready to go.

thanks! confirmed on my side that this is 👍

[jimexist]

However, it still shows a warning that Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.

yes because we still have one thing left: migrate maven plugin to maven-publish plugin. that's a bigger task to handle so i'll do it later, along with upgrading to gradle 7.x

I've put up:

• THRIFT-5581: java lib to upgrade to gradle 7 and migrate from maven to maven-publish plugin #2601 to migrate to gradle 7.4+ which is the latest version