How can I isolate against the Gradle runtime dependencies?


In one of my plugins I have to create my own ClassLoader to make sure I do not include the runtime libraries that Gradle already provides (to avoid library version conflicts). The plugin is written in Groovy so I do want to include the provided Groovy library to be able to actually run the plugin code. To get the available library I use the following code:

ClassPathRegistry classPathRegistry = new DefaultClassPathRegistry()
URL[] runtimeClasspath = classPathRegistry.getClassPathUrls('GRADLE_RUNTIME')

This works fine in milestone 3 but not in milestone 5. I haven’t had a look at the Gradle code yet but I guess the variable GRADLE_RUNTIME is not available anymore. This is the error I get:

Cause: unknown classpath 'GRADLE_RUNTIME' requested.

I could work around this by requiring users to include a Groovy library in the classpath but this feels kind of clunky. In general I think this question is part of a bigger discussion around the fact that Gradle should provide its own ClassLoader for plugins out-of-the-box which should be addressed at some point of time. For now I’d be interested what the recommended way is to get a reference to Gradle’s runtime classpath (optimally compatible in any milestone version of 1.0).



Have you tried with parent-last class loader delegation? That would be better than relying on Gradle internals.

I haven’t tried that yet but will certainly give it a shot.

Did my suggestion work?

In milestone 5, your plugins are isolated from the Gradle internals. You should not have to do anything special.

@Peter: Sorry, I haven’t found the time to work on this yet. I will have a look at this on the weekend though.

@Adam: I am not sure if I understand this correctly. How does milestone 5 behave if you wrote your plugin in Groovy? Will you have to apply the Groovy plugin to your project to make this work? Does this mean that all plugins have their own ClassLoader by default?

No, you wouldn’t have to apply the Groovy plugin. Groovy is considered part of the Gradle API, so is visible. Even if it weren’t you’d declare it a dependency of your plugin, and it would be included in the plugin classloader.

The plugins that you declare in a buildscript { } section all live in the classloader for that build script, so they’re not yet isolated from each other. The only visible change we’ve made so far is to isolate build scripts + custom plugins from Gradle’s core and plugin implementations. Isolating plugins from each other is yet to happen.

Thanks, that explains it pretty well. I got rid of my dependency to Gradle internals.