Adding plugin classes to project's compileClasspath

I have a plugin which contains some JUnit extensions. When a project applies this plugin I would like to add these extensions to the project’s compileClasspath.

Is there a way to do this?

The general recommendation would be that the plugin implementation adds a dependency to the project. Technically, that dependency could be the plugin JAR itself, but does the plugin actually need these JUnit extensions as well? It would be more normal for the plugin to just add a dependency on the extensions that are published in a separate module to the project, but could also depend on them itself, if that’s really needed. If you really wanted to write out classes from the plugin classpath to a location in the project, you could, and then configure the project to also depend on those files, but I’m having trouble coming up with a use case where that is more ideal than the alternates.

Thanks as always James!

Right, this is what I am trying to achieve.

No it does not. And technically the 2 (plugin code v. JUnit code) are “distinct” in that they do not rely on each other. So…

I can definitely understand that. And that’s probably going to be the best way forward based on your reply. I was just trying to avoid a separate project/module for the JUnit extensions because its like 3 classes.

Interestingly enough, using the legacy apply plugin syntax, I was actually able to hack this by looking at the project’s buildscript’s classpath Configuration and find my plugin jar. But that stopped working once I switched to the new plugins block to apply the plugin.

So all told, it sounds like publishing a separate module for the JUnit extensions will be the best even though I wanted to avoid that.

Relatedly… is there a way to add imports to a project’s buildscript? Atm to use custom Tasks, e.g., I have to give an explicit import for the task’s FQN. Would be much nicer to use the task’s simple name without import like the built-in tasks (Test, Copy, etc)

It’s not technically adding imports, but there’s a number of plugins that do this same thing conceptually. The import ends up in the plugin and then a reference to the class is saved in a short property of the same name. The variation I use normally is below. It’s primarily a Groovy DSL trick, but won’t hurt anything in the Kotlin DSL.

private void configureSimpleTaskNames(final Project project) {
    project.getExtensions().getExtraProperties().set("MyTask", MyTask.class);
}
1 Like