Defer gradle task implementation dependency resolution to the actual execution (not in buildscript classpath)


some of my builds have become quiet big applying many custom plugins that have various external dependencies.
While they are all required, some of them provide features only a small subset or even no developer ever needs or they rely on external libraries which may change depending on the external system version they interact with - requiring new releases just because a plugin dependency needs to be updated.

A while ago I discovered in the gradle jacoco tasks that one can run ant tasks in a dedicated classloader that can be enhanced with libraries that are dynamically beeing resolved from a configuration. A implementation like this can use a custom configuration to provide a library just for the execution of this task and it’s classes are not applied to the overall buildscript classpath:

        final Configuration jacocoAntConf = getProject().getConfigurations().getByName(JacocoPlugin.ANT_CONFIGURATION_NAME);

        getAntBuilder().withClasspath(jacocoAntConf.getAsFileTree()).execute(new Closure<Object>(this, this) {
            public Object doCall(Object it) {
                final GroovyObjectSupport ant = (GroovyObjectSupport) it; // AntBuilderDelegate
                // declare your custom task
                ant.invokeMethod("taskdef", typedefParams);
                // execute completly independend
                ant.invokeMethod("antTaskName", params);
                return null;

I sure it’s not the best way to decouple the tasks implementation internal dependencies by having to write a ant task and run it like this.

Can anyone provide an example or documentation on how to do that without ant?

In the end it boils down to decouple or isolate dependencies of plugins from one another and delegate dependency resolution to the execution of a task and not having to resolve them while configuring the build.

kind regards

I think what you are after is the worker api with classpath isolation: Developing Custom Gradle Task Types

Thank you, I’ll have a look at that.

1 Like