Gradle 9 compatibility#1535
Conversation
|
We are upgrading to gradle 9 in a different branch. Also I don't feel comfortable with a first-time contributor making changes to our build system. I recommend you read |
|
Ok, good to know that you are already on it. I searched for Gradle relates issues and branches before creating the PR, but didn't find anything, therefore I assumed it was fine to create the PR - I am sorry, if not. I am also not exactly a first-time contributor: Ben merged a PR from me in 2021 (b1eed96) and I am the maintainer of the Processing packages for Arch Linux since a least six years. Anyway, since I am also not exactly a regular contributor, I re-read the contribution guidelines, but I still do not really see an obvious mistake I made by creating the PR. Maybe the fact, that I was not able to test the change on a Mac or should I have created an issue before creating the PR? Could you please point me to the thing I am missing? Last question: Is there an issue regarding the Gradle 9 migration I could subscribe to? The Arch packages I maintain contain my patch right now to avoid the heavy Gradle 8 dependency, but I'd like to remove it as soon as your branch has been merged into main. |
Currently the build process fails with Gradle 9 due to a depreciated statement in app/build.gradle.kt. The relevant part of the error message is:
This PR enables Gradle 9 compatibility by replacing the
commandLine(...)statement withRuntime.getRuntime().exec(arrayOf(...)). After this, the build process runs smoothly on Linux.Important: Even though I am pretty sure that the new statement will work, I was not able to test it on MacOS, which seems to be the only system that actually executes the modified line. This should be done by a reviewer before merging the PR.