Then I get a ClassCastException from the Artifactory plugin, which I reference from my custom build plugin:
> Cannot cast object 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention@192b4148' with class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention' to class 'org.jfrog.gradle.plugin.artifactory.dsl.ArtifactoryPluginConvention'
If I remove the classpath for proguard, everything works again. It’s not specific to proguard, anytime I add a 2nd classpath definition, it breaks with this exception. From a bit of Googling most people seem to get this exception when there are “multiple versions” of a plugin on the classpath…
What could be causing this? Does this sound like something special in the Artifactory gradle plugin, or is this more of a general buildscript gotcha with multi-project builds??
I’m currently experiencing a similar phenomenon with a custom plugin I have written. Under some circumstances I also get such a strange ClassCastException for a (random) class that is part of the plugin project. It also states two times the exact same class name.
I wasn’t yet able to figure out a pattern when this happens or for which class it happens. The plugin is used only for Android modules in a multi-project setup. Everything works fine when the plugin is applied to a simple Android dummy app but it fails when the plugin is applied to the relevant modules of the “real” project. The dummy app is smaller and simpler but I thought it should be comparable enough to the real thing but easier to test the plugin. So I can’t really tell if the plugin just works on accident for the dummy app or in which ways the dummy app is simpler than the real project.
In particular I get this error from a task class which in turn uses other classes from the plugin project. On the other hand a different but also very simple task class works without any problems. Also the plugin class itself which is interacting with some other classes doesn’t seem to be an issue.
So maybe it’s only an issue for task classes although I am not aware of any limitations regarding what you can do or you can not do inside a task action.
I think this is more a gotcha with multi-file builds, as I’ve seen it happen within a single project too.
The basic gist seems to be that Gradle will share the classloader for two build scripts with the same classpath. But if the classpath is not identical, it won’t share them at all, so you end up with the class referenced from one file not being equal to the same class referenced from another file.
The only workaround I’ve seen so far is to make sure the list of dependencies exactly matches, but it’s a live problem in our current build which we’re searching for better solutions for.