Fix for Kotlin 1.7 breaking changes #214
Conversation
fixes: java9-modularity#212 The gradle plugin for Kotlin 1.7 included breaking changes, including making `KotlinCompile` no longer derive from `AbstractCompile`, breaking this plugin. (See https://kotlinlang.org/docs/whatsnew17.html#changes-in-compile-tasks). The fix is to factor out the information required from compile tasks into a `CompileTaskWrapper` interface and provide different impls for tasks derived from `AbstractCompile` vs those that are not (like `KotlinCompile`). The latter uses reflection to access the needed methods.
big-andy-coates
force-pushed
the
issue-212
branch
from
daf2c09 to
e9ffc69
Compare
|
@siordache, this change should get us close to a solution to the breaking change in the Kotlin Gradle plugin v1.7. However, I'm seeing a test failure in The failure is due to the following extra output at the start: At this time I'm not sure if this is due to an issue with my changes, or another change to do with the Kotlin plugin. Though my debugging suggests the new code is resulting in the same functionality. It may be this line just needs ignoring, but I don't feel happy doing that without a more thorough understanding of what's causing it. Any help / pointers appreciated. :) |
Issue was that nothing was actually using the `javax.annotation` module in the project, i.e. a bug in the test project. For some reason updating the Kotlin jars caused the issue to be displayed. Fixed by having a module depend on the module. Also added a use of one of the types from one of the patched jars to ensure it working.
|
Never mind @siordache, I found and fixed the issue. The PR is really for review. |
|
Thanks for this PR! |
fixes: #212
The gradle plugin for Kotlin 1.7 included breaking changes, including making
KotlinCompileno longer derive fromAbstractCompile, breaking this plugin. (See https://kotlinlang.org/docs/whatsnew17.html#changes-in-compile-tasks).The fix is to factor out the information required from compile tasks into a
CompileTaskWrapperinterface and provide different impls for tasks derived fromAbstractCompilevs those that are not (likeKotlinCompile). The latter uses reflection to access the needed methods. (I've gone with reflection as it means we don't need to bring in Kotlin plugin dependencies).