Override dependency version of a library a plugin does bring to the build classpath

Help/Discuss
1

Hi,

I’ve got the problem, that I do have two plugins in my build file, that put the same library in a different version on the classpath.

Unfortunately they are not compatible and having the same classes in different versions on the classpath does bring all sort of problems - but I know (because I forked the plugin, changed the dependency version, recompiled etc.), that upgrading it to the version I know both work with, would fix that.

Is there a way in gradle itself to use a plugin and remove / switch an artifact / artifact version it depends on, without changing the plugin source itself, recompile stuff and release a new version (which obviously would work too - but I am not in control to do that on the upstream source)?

2

If both plugins are in the same classpath, there should be conflict resolution and only the higher version should land on the classloader.

Or do you need a “3rd” version with which both are compatible?
Then you could for example use buildscript { dependencies { constraints { classpath("the:dep:3.0") } } }.

3

Unfortunately that is not what is happening, I’ve got e.g. this:

Caused by: java.lang.NoSuchMethodError: 'void com.fasterxml.jackson.core.base.GeneratorBase.<init>(int, com.fasterxml.jackson.core.ObjectCodec, com.fasterxml.jackson.core.io.IOContext)'

Reproducer is here (GitHub - tkrah/cyclonedx-482)

gradlew child:cycloneDx

But I am going to try your suggestion with the constraint.

4

Because the premise is not fulfilled and then also the constraint will not help.
At least if the node plugin is one of the related plugins.
You depend on it from buildSrc.
buildSrc and its dependencies are in a parent classloader of the root build script class loader.
So due to class loading rules it overwrites any version that might be introduced by a plugin in a build script classpath.
You either need to stop using buildSrc and instead us an included build instead so that proper conflict resolution can be done, or add such a constraint (or all related plugins) to the buildSrc build script, so that the conflict resolution can happen there.

1 Like
5

Okay, I just did what the documentation told me / suggested, it is written here:

https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources

Quote:

…
The directory buildSrc is treated as an included build.
…

So you actually said it is not an included build if I use buildSrc, which is the opposite of what the docs said - you must admit, to users which are not that deep in the gradle development itself, it is not that easy to get behind those nooks and crannies here.

Thanks for your valuable feedback.

6

Yeah, the docs are a bit misleading.
buildSrc is very similar to an included build, especially since Gradle 8.0.
But it is still special in some nuances and only “treated like an included build to great lengths”, but still is not an included build and has some differences.