setFileMode slated for removal in Gradle 9.0

[bell345]

When building with a newer version of Gradle (8.9), there is a deprecation warning caused by the use of setFileMode in RustAndroidPlugin.kt, see:

rust-android-gradle/plugin/src/main/kotlin/com/nishtahir/RustAndroidPlugin.kt

Line 279 in 898d9fd

fileMode = 493 // 0755 in decimal; Kotlin doesn't have octal literals (!).

This API is currently deprecated and is slated for removal in Gradle 9.0, due for release in Q2 2025. Therefore, this usage should be replaced with an implementation with the newer filePermissions(Action) API.

I am planning to contribute a quick PR in a few hours to resolve this issue.

[bell345]

Now I see that the new API doesn't exist in the Gradle version used for this plugin (4.0.1) because it was introduced in 8.3.

I'm now creating a fork to update to the latest versions of Gradle and AGP (8.12 and 8.7, respectively). If there is interest I will consider making a pull request.

[ncalexan]

@bell345 I think we'd definitely be interested. I don't have a strong understanding of how Gradle versions for plugins work with backward compatibility: if we build r-a-g with Gradle 8, is it easy to use in projects with Gradle 7 and below? I think the answer is no, and if that's true, I think we'd probably need to do some work to understand usage in the wild to understand how far forward we can pull the plugin Gradle version.

[bell345]

So I've been working on trying to modernise the plugin implementation and test suite. There are actually several deprecated features that are planned for removal in Gradle 9:

• As mentioned, the setFileMode API
• The VersionNumber API, which was originally intended only as an internal API
• The Project.buildDir variable, in favor of a more awkward layout.buildDirectory API
• Automatic convention for testClassesDirs and classpath in newly created Test tasks

This isn't even counting all of the idiomatic things that Gradle now recommends, such as Java toolchains, the use of Property everywhere and the plugin block.

Initially I tried to only focus on the deprecation warnings, but I got sidetracked and ended up doing a lot more work to get the project to resemble a Gradle plugin as intended in 2025. I also replaced the Groovy/Spock tests with Kotest; there isn't really much justification for that move, besides my personal dislike of Groovy.

I had attempted to try and keep compatibility with older AGP versions but I've had to deal with endless baffling errors such as "Protocol message contained an invalid tag" and "module cannot be null" (even when it is not null). After basically a week straight working on compatibility issues, I've decided to publish my forked version as "v0.10.0" with limited backwards compatibility on the Gradle plugin repository for my own use (as of writing this comment it is under review).

Given the scope of the changes far exceeds this one issue (see my self PR for more details), I might consider making smaller, focused PRs into the upstream repository where the changes are more appropriate. For example, I updated the documentation to feature Kotlin DSL prominently and with a proper target matrix table; that may be useful in of itself outside of the modernisation changes.

[Rawa]

Bumping this issue since the entire plugin is now incompatible with latest release of gradle. Upgrading will yeild the following error:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
   > 'org.gradle.api.tasks.AbstractCopyTask com.nishtahir.GenerateLinkerWrapperTask.setFileMode(java.lang.Integer)'

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to generate a Build Scan (Powered by Develocity).
> Get more help at https://help.gradle.org.

BUILD FAILED in 49s
3 actionable tasks: 3 executed

@ncalexan How is your time looking nowadays? Anytime to upgrade this plugin? We are dependent in our build chain on this plugin and would have to fork it unless progress is made.