search

nebula-plugins / gradle-resolution-rules-plugin

Gradle plugin for providing reusable dependency resolution rules.
Apache License 2.0
45 stars 19 forks source link

JDK 13+ Compatibility #126

Closed Fleshgrinder closed 4 years ago

Fleshgrinder commented 4 years ago

I have a Gradle multi module setup where I apply the plugin exactly as shown in the README. Everything works with JDK 11 but if I switch to JDK 13 or 14 I get the following exception(s):

org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':foo'.
// …
Cause 1: java.lang.NoSuchFieldException: modifiers
    at nebula.plugin.resolutionrules.ConfigurationsKt.setField(configurations.kt:66)
    at nebula.plugin.resolutionrules.ConfigurationsKt.setName(configurations.kt:50)
    at nebula.plugin.resolutionrules.ConfigurationsKt.copyConfiguration(configurations.kt:26)
    at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension$rulesByFile$2.invoke(plugin.kt:123)
    at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension$rulesByFile$2.invoke(plugin.kt:110)
    at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
    at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension.getRulesByFile(plugin.kt)
    at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension.ruleSet(plugin.kt:150)
    at nebula.plugin.resolutionrules.ResolutionRulesPlugin$apply$1.execute(plugin.kt:80)
    at nebula.plugin.resolutionrules.ResolutionRulesPlugin$apply$1.execute(plugin.kt:37)
    at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1$1.run(DefaultCollectionCallbackActionDecorator.java:100)
// …

Not sure where this stems from but it seems that this plugin is not compatible with JDK 13+ (I didn't test JDK 12). It should be fairly simple to reproduce, just create a project with a submodule and apply the plugin as stated in the README and try running ./gradlew tasks.

carl-mastrangelo commented 4 years ago

Just ran into this too. @chali it looks like mutating final fields is not going to work long term. I have a longer stack, and it doesn't seem to be something that needs too exotic. It would be very helpful to fix this and allow nebula users continue to upgrade.

Cause 22: java.lang.NoSuchFieldException: modifiers
        at java.base/java.lang.Class.getDeclaredField(Class.java:2569)
        at nebula.plugin.resolutionrules.ConfigurationsKt.setField(configurations.kt:66)
        at nebula.plugin.resolutionrules.ConfigurationsKt.setName(configurations.kt:50)
        at nebula.plugin.resolutionrules.ConfigurationsKt.copyConfiguration(configurations.kt:26)
        at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension$rulesByFile$2.invoke(plugin.kt:123)
        at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension$rulesByFile$2.invoke(plugin.kt:110)
        at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
        at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension.getRulesByFile(plugin.kt)
        at nebula.plugin.resolutionrules.NebulaResolutionRulesExtension.ruleSet(plugin.kt:150)
        at nebula.plugin.resolutionrules.ResolutionRulesPlugin$apply$1$$special$$inlined$onExecute$1.execute(projects.kt:16)
        at nebula.plugin.resolutionrules.ResolutionRulesPlugin$apply$1$$special$$inlined$onExecute$1.execute(projects.kt)
        at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:100)
        at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingAction$1.run(DefaultListenerBuildOperationDecorator.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
        at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingAction.execute(DefaultListenerBuildOperationDecorator.java:150)
        at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:95)
        at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:83)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:245)
        at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:157)
        at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:346)
        at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:249)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:141)
        at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
        at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
carl-mastrangelo commented 4 years ago

@DanielThomas If you haven't already, it seems like the ideal long term fix is to file an issue to Gradle. The reflection used here seems like it is working around a Gradle API limitation.

DanielThomas commented 4 years ago

Release 7.7.7 will go out in the next hour.

DanielThomas commented 4 years ago

@carl-mastrangelo unlikely to ever land. The move to core locking will remove the need for most of this logic and the eventual goal is to not to need resolution rules artifacts either - these rules will be published as Gradle metadata.

carl-mastrangelo commented 4 years ago

The move to core locking will remove the need for most of this logic and the eventual goal is to not to need resolution rules artifacts either

Is there a tracking issue for this?