Adding jar files to the project classpath from a custom plugin

Old Forum Archive
1

Hi,

I have created a custom plugin which uses some external jar files to accomplish its tasks. Since this plugin will be used a lot of places in our organization I don’t want each project to add a buildscript{} block and add the dependencies to these internal deps.

Is there a way for me to provide these classes to all users of my plugin?

I’ve tried several things, but the only way I have gotten it to work is by adding a buildscript{} block in each project

2

You just need to publish the plugin Jar to a Maven or Ivy repository, along with the usual dependency descriptor. Then transitive dependency management will take care of the rest.

You still need a ‘buildscript’ block per build (not project) to bring in the plugin Jar itself.

3

I did upload it to a maven repo, but maybe I have set the dependency scope incorrect? I have the following dependencies in my plugin:

dependencies {
    compile gradleApi()
    groovy localGroovy()
    compile "com.googlecode.jslint4java:jslint4java:2.0.3"
        compile "com.github.timurstrekalov:gradle-saga-plugin:1.4.0"
}

then I have added the plugin I’ve created in the init.gradle script to be able to use it in all internal projects.

buildscript{
         dependencies {
           classpath "my.company.gradle.plugin:customplugin:1.0.0-SNAPSHOT"
       }
    }

when I run gradle tasks I get an error saying

Could not generate a proxy class for class xx.xxx.x.x

and I see in the stacktrace that it cannot find a class inside one of the dependencies specified above.

4

Looks good. I would first check the plugin’s POM, then try whether putting the ‘buildscript’ block into ‘build.gradle’ makes a difference. Also, don’t forget to declare a repository in the ‘buildscript’ block.

5

So I’m in a somewhat odd scenario. I have a plugin that uses an annotation processor. Can I put the annotation processor in the plugin or should I package it separately? When the annotation processor is in the same artifact as the plugin, I can’t use the solution you mention above, because I’m not talking about a runtime dependency for the plugin, I’m talking about an annotation processor that needs to get inserted onto the target classes classpath during compilation.

Right now, I’m explicitly adding the dependency, but it’s hard-coded, so I’ll have to update it on every version change.

6

In that case, the plugin should probably declare the annotation processor as a ‘compile’ dependency of the project that the plugin gets applied to. Potentially it could also declare the repository where to get the annotation processor from. The plugin could also offer a way for users to specify the version of the annotation processor. Gradle’s code quality plugins (‘FindBugsPlugins’, ‘CheckstylePlugin’, etc.) work in a similar way.

7

I’ll have to see what those tools do. I’m actually adding the dependency just to the task’s classpath (with type: JavaCompile). I didn’t want to put it on the classpath for unrelated tasks, although that would probably be harmless.

I figured it would be reasonable to just assume they want the same version that’s associated with the plugin, since there may be dependencies. I just wasn’t sure if there were a way to somehow get a reference for the artifact that contains the current plugin, but that kind of reflection would be crazy and almost never useful.