ClassLoader problems using ModuleRevisionId

Help/Discuss
1

I am attempting to write a plugin that implements a bespoke repository format,
i.e. an alternative to maven/ivy/flatDir.

To do this I have made use of the class ‘org.apache.ivy.core.module.id.ModuleRevisionId’ in the plugin.

However when building the plugin, gradle complains that it has two copies of this class,

java.lang.LinkageError: loader constraint violation: when resolving method “org.gradle.api.internal.artifacts.DefaultModuleVersionIdentifier.newId(Lorg/apache/ivy/core/module/id/ModuleRevisionId;)Lorg/gradle/api/artifacts/ModuleVersionIdentifier;” the class loader (instance of java/net/URLClassLoader) of the current class, …AbstractModuleComponentResolveMetaData, and the class loader (instance of org/gradle/internal/classloader/MutableURLClassLoader) for the method’s defining class, org/gradle/api/internal/artifacts/DefaultModuleVersionIdentifier, have different Class objects for the type org/apache/ivy/core/module/id/ModuleRevisionId used in the signature

2

I originally posted this in ‘Bugs’ but it is not really a bug, I think.

The issue is to do with the hierarchy of classloaders that is set up by the gradle launcher.

As far as I can see, a plugin is run in its own class loader that is in some way isolated from the class loader that does the repository resolving.

I believe I have got around this issue by accessing an ancestor class loader and using this to load other classes in my plugin. I’m sure that this uses a whole load of non-gradle-api stuff, but it does get me around this class loader problem. (currently).

Anyone with a better / cleaner solution, do let me know.