-
Notifications
You must be signed in to change notification settings - Fork 54
Avoid using old Variant API extending JavaCompile task #1886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| // One of the changes is the removal of direct access to the JavaCompile task provider. | ||
| // Because we need this task in the different configurations of the workaround, | ||
| // we configure the workaround directly at the JavaCompile task level. | ||
| project.afterEvaluate { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In one of our tests, we access the JavaCompile task to verify the compiler arguments defined in the task.
This verification happens before the configuration of the jdkImage workaround, which results in an error.
To address this, I wrapped the configuration in afterEvaluate.
I’m not fully convinced by this approach, but it ensures the plugin is configured before the root project finishes its build configuration phase.
We should discuss whether there are cleaner alternatives here.
For reference, see the test: workaround is enabled when enabled via system property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear -> wrapping the variant configuration into afterEvaluate is necessary only for our test to pass, not actually necessary for the workaround to be applied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I added it only for testing purposes. But at the same time, I thought it wasn’t uncommon to configure Java compiler tasks in the project.
|
What is the downside of applying the workaround to all |
|
It’s not really a downside, but it does mean changing how the plugin has worked until now, since it has relied entirely on the AGP Variant API to configure the Java compile task associated with the build variant. |
|
updated this PR to alpha05, still the java task provider fix has not been included |
|
AGP 9.0.0-alpha06 introduces the new configureJavaCompileTask API, which provides a dedicated configuration hook for the Java compile task(#1894). |
Since AGP 9.0.0-alpha04, the new DSL has replaced the old DSL implementation with the Variant API.
Our dependency on the old API was discussed in gradle/android-cache-fix-gradle-plugin#447.
Technically, we could use the AndroidComponent variant selector, but the workaround requires access to the JavaCompile task provider. This is a breaking change, as there is no equivalent in the new API.
AGP currently provides an opt-out flag to continue using the old behavior, which we enabled in the PR updating to Alpha04. However, this option will be removed permanently in AGP 10, so we need a long-term solution.
As an initial step, this PR configures the JDK transform directly when configuring the JavaCompile task. Further analysis and testing will be required to verify the effectiveness of this approach.