Unable to get plugin class in scope in build script

Help/Discuss
1

I’ve been creating my own gradle plugin for the last few days (partly for learning, and partly to clean up some gradle build scripts I have laying around), however I’ve run into a problem that I can’t figure out how to fix. In my plugin jar there is an interface named me.alxandr.gradle.bintray.maven.MavenPackage, yet when I try to import it I get an error saying that it can’t be found. This is really weird, because the plugin is obviously running (I’m seeing output from it, and it’s tasks are registering).

Currently I’ve done a hack to get around this as following:

project.ext.MavenPackage = MavenPackage

This just makes MavenPackage an available name in the buildscript, which works, but I loose any editor support for it cause it’s entirely dynamic. Is there any way I can (from my plugin) get the buildscript to import a package when it’s applied? Like how MavenPublication is in scope without me needing to import it. If not, why can I not import classes from my plugin package?

The entire source code is available at https://github.com/Alxandr/gradle-utils. You can see an attempted here: https://github.com/Alxandr/gradle-utils/blob/master/gradle/publish.gradle#L1. The current code works as is (with the hack explained above), but I’m just looking for a better way to do this.

2

Script plugins like your publish.gradle have an isolated classpath. You need to add a buildscript block to it which adds your plugin to the classpath of that script.

3

I see. I’ll try that :slight_smile:

Does that mean I can do plugin { id ... } too? Otherwise I’m both specifying the plugin (in the main build script), and the classpath (in the external script). Also, does that mean I don’t need to list it in the main build script at all?

4

The plugins block is not yet supported in script plugins, but we’ll definitely add that in the future.

If you put the plugin to the classpath of a script plugin, then you should not add it to your projects. Since the classpaths are isolated, you’d end up with two versions of the same class otherwise. This is something we’ll fix in the future using the plugins block.

5

Right. Thanks for the reply :slight_smile:

I decided to remake my plugins dsl though, so I no longer need the type in scope. I was originally using the metamorphiscontainerthingy (the one you use for publications) so that I could write packages { myPackage(MavenPackage) { ... } }, but I figured I didn’t need the ability to register new ones from outside the plugin, so I just went with a custom container and methods for the different package types packages { maven('myPackage') { ... } }, which doesn’t need anything in scope :slight_smile: