Conflict with shaded dependency from gradle-docker-plugin

[smirnovdvde]

There are shaded dependencies in gradle-docker-plugin. If in the build gradle script in project there is another gradle plugin or something in buildscript classpath, that uses, for example, docker-java-api, which is shaded in the gradle-docker-plugin, some conflict among dependencies could happen.

Expected Behavior

There is no shaded dependencies in your plugin. If some conflicts happened, it would be possible to resolve via standard gradle tools.

Current Behavior

Now in case of conflicts between shaded dependencies from plugin and another sources from class path, there is no way to resolve it.

Context

Get stuk with current development of my project.

Steps to Reproduce (for bugs)

Your Environment

[bmuschko]

I don't fully understand your situation. If a dependency in this plugin was relocated, then it should not have an effect on other plugins that use the same dependency in it's original package. You probably have a situation where a transitive dependency in its original form appears in different plugins. Plugins in Gradle at this time do not have separate classloaders so that's something that needs to be fixed in Gradle itself.

[smirnovdvde]

No, it is not in gradle itself, problem is in plugin, i had problem like described here #1144 and i use plugin with version 9.4.0

[bmuschko]

What I am saying here is that the real solution would be separate classloaders for plugins classpaths in Gradle itself which would not require relocating packages and clashes between dependencies required by plugins.

AFAIR, we had to revert the change you are referring to, as relocating JNA caused issues.

[smirnovdvde]

sorry i dont understand, you are writing that "we had to revert the change you are referring to, as relocating JNA caused issues". Does it mean they are already reverted and corresponding version of plugin is released? If yes, i still can observe shaded dependency in version 9.4

[wolfs]

AFAIR, we had to revert the change you are referring to, as relocating JNA caused issues.

@bmuschko Is this still true? I think it is perfectly fine when a plugin relocates and shades dependencies to avoid clashes with other plugins. Though if it only shades a dependency, like e.g. JNA, then this causes clashes with other plugins that also might bring in JNA. If the dependency is shaded, then you can't change the version the plugin is using to avoid the conflict, that is particularly bad for JNA. Would it be an option for you to keep JNA as a transitive dependency of the plugin, while keep shading and relocating the other dependencies? So build engineers could resolve the possible JNA version conflict?

[bmuschko]

@wolfs My last commit is from Dec 21, 2023. No changes have been made in the meantime. JNA isn't shaded anymore if I do remember. The right solution here would be that the Gradle runtime creates a separate classloader per plugin so that plugin authors wouldn't even need to shade dependencies. It's been an ask for a long time.

[wolfs]

@bmuschko Relocation doesn't work for anything that uses JNI, like e.g. JNA. Nor does classloader isolation, since you can load a certain native library only once per JVM, not on multiple classloaders.
My understanding is that in the plugin, all the transitive dependencies are shaded (aka included in one JAR), though not all are relocated. And if there is another plugin using JNA then there is a version conflict that can't be resolved, since the build author can't change the version of JNA shaded in the docker plugin jar. That is why I think it would be good if the JNA jar would not be shaded but the plugin would depend on it and the build author can change the transitive dependency to avoid conflicts between multiple plugins.

For the problem that I am facing right now, aka the Develocity plugin not working with the docker plugin, it would also be enough if you could release a new version of the Docker plugin that shades the latest version of JNA.

[bmuschko]

Thanks for providing some background info on the issue. Would you mind sending me a PR for this? I am currently underwater with other work.