I’m running into a problem trying to use both the jib and srcclr gradle plugins in a single project. As soon as I add the srcclr plugin to my project plugin dependencies, jib fails with the error:
Execution failed for task ':service:jibDockerBuild'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: 'void org.apache.commons.compress.archivers.tar.TarArchiveEntry.<init>(java.nio.file.Path, java.lang.String, java.nio.file.LinkOption)'
It looks like this is due to one plugin referencing apache commons-compress 1.20, and the other referencing version 1.21. I’ve seen other posts that mention using
buildscript to limit a plugin’s effect on other plugin’s search paths, but I’m not sure how to use that solution in a gradle conventions plugin project.
I’ve created a test case that only uses these two plugins (plus
java) and pushed the source to GitHub - pshapiro4broad/gradle-test-project. I’m using gradle 7.4 and the latest versions of both plugins.
A fix would be nice, but advice on what to try next would also be helpful. Thanks!
After more debugging I now have a workaround. I found that adding an explicit dependency for the newer commons-compress library causes gradle to ignore the older one requested by the plugin. To be clear, the fix was adding this line:
To the the
If I comment out that line and execute the
jibDockerBuild task, it works just fine.
The default conflict resolution by Gradle is to use the newer version, so 1.21 is what is used.
Must be something local to you that breaks it.
Maybe you have some init script or something?
Ah, it’s less a conflict. The problem is, that the
srcclr is evil.
It builds a fat jar with its dependencies included which might be ok to avoid conflicts with other dependencies, but should anyway be avoided as it bloats every plugin jar up then as hell.
But the problem is, that it does not at least shade the libraries it ships.
So you end up with two versions of the classes on the classpath, once in
commons-compress and once in
srcclr jar, even with your “work-around”.
Whichever comes first in the class path will be used and it was probably just a coincidence that it worked for you by adding that line.
srcclr really insists on building a fat jar, it should at least shade the dependencies it ships to not cause such a mess.
Thanks for tracking this down. I figured it was a problem with jib or srcclr but wasn’t sure which one. I’ll file a bug with srcclr and perhaps they’ll fix it.