Best practice for including a dependency in a 3rd party plugin?

Help/Discuss
1

I’m trying to make my jar file available to a 3rd party plugin. The approach I’ve found to work is to add

buildscript {
    dependencies {
        classpath ("my-group-id:my-artifact-id:version")
    }
}

to the top-level build.gradle file.

My question is, is this the best way to configure this? Adding it to the buildscript doesn’t sound the most obvious place for when someone will come to look at this at a later date.

2

Ideally, the third party plugin should load your class(es) via a different classloader (eg URLClassLoader) rather than using the buildscript classloader. Then, the third party plugin would allow the classloader jars/directories to be configured in Gradle’s configuration phase (eg via an extension object or by adding dependencies to a custom Configuration)

Which third party plugin are we talking about? Is it open source? Or something developed in house?

3

Thanks for coming back so quickly.

The plugin is OWASP dependency check. https://github.com/jeremylong/dependency-check-gradle.

The reason I’m adding my own jar is to make a suppressions.xml file available. It means I can publish the xml file from one repo and make it available to all other repos.

The suppressions.xml file can be discovered from the classpath, but I can’t see how that is possible to add my dependency from the plugin configuration itself.

4

As usual, this would’ve been much easier to give help if you included your current config.

You could do something like

apply plugin: 'org.owasp.dependencycheck'
configurations {
   suppressions { transitive = false } 
} 
dependencies {
   suppressions 'foo:my-suppressions:1.0'
}
dependencyCheckAnalyze {
   suppressionFiles = zipTree(configurations.supressions.singleFile).matching {
      include 'path/to/suppressions.xml'
   } 
}

Some Gradle purists (including myself) would move the unzipping to another task so that the dependency download is done in the execution phase rather than the configuration phase in my example above

1 Like
5

Thanks for your help with this. Really sorry about not providing enough details. I thought it was more of a general question rather than a specific request, but see your point and will try to give as much info as possible next time.

Thanks for your hint about moving the unzipping to the execution phase. I’ll look into this.

6

My original statement (that the third party plugin should load resources using a configurable classloader instead of the buildscript classloader) still holds true. If the OWASP dependency check plugin had implemented this the configuration would be much simpler (we wouldn’t need zipTree(…))

Its just lucky they support loading via file as well as by classpath resource

Eg ideally you’d configure like:

apply plugin: 'org.owasp.dependencycheck'
dependencies {
   owasp 'foo:my-suppressions:1.0'
}
dependencyCheckAnalyze {
   suppressionFile = 'path/to/suppressions.xml'
}