How to strictly specify the version of a transitive plugin dependency used by another plugin?

I have a Gradle project with a lot of modules. Some modules use plugin-a via specifying it in build.gradle.kts

plugins {
    id("plugin-a")
}

With gradle buildEnvironment I see that
plugin-a depends on “net.razvan.jacoco-to-cobertura:net.razvan.jacoco-to-cobertura.gradle.plugin:1.2.0”.
What should I do to replace version 1.2.0 with 1.3.2 for all modules in project?

If by “module” you mean “project” and by “project” you mean “build”,
the simplest way is to add that version of that plugin to the root project build script classpath.

That classpath lands in a class loader that is in the ancestry of the other build scritps’ classpath class loaders, so will win over the version resolved there.
Don’t get fooled by buildEnvironment output, that will not reflect that.

So just add id("net.razvan.jacoco-to-cobertura") version "1.2.0" apply false to the plugins { ... } block in your root project build script and you should have the result you intended.

1 Like

This doesn’t work.
Only adding id("net.razvan.jacoco-to-cobertura") version "1.2.0" apply false to the plugins { ... } block in child project works.
Is there a mechanism to add conditionally on presence plugin from root build.gradle.kts/settings.gralde.kts?
Something like

buildscript {
    configurations.all {
        plugins {
            id("net.razvan.jacoco-to-cobertura") version "1.3.2" apply false
        }
    }
}

How does “This doesn’t work.” manifest?

And is the shown what you tried in the root project? Theplugins { ... } block has to be top-level, not nested in anything.

Thanks a lot! It works ) The problem was with my local caches.

1 Like

Why buildEnvironment doesn’t show real version?

That task shows the classpath of the buildscript you are calling it for.
But the version is coming from a parent class loader, not from that classpath.
That’s why I said you should not get fooled by that. :wink:

1 Like