artifactory-client-java icon indicating copy to clipboard operation
artifactory-client-java copied to clipboard

Version 2.8.5 breaks build depending on new version of commons-io module

Open deporcali opened this issue 5 years ago • 5 comments

If your projects depends on a newer version of commons-io (i.e. commons-io:commons-io:2.6) then the new version of this library (currently 2.8.5) will break the project build since this new version has an old version of commons-io embedded in it (see screenshot).

So some recommendations:

  1. Update the README to use org.jfrog.artifactory.client:artifactory-java-client-services:<specific-version> instead of org.jfrog.artifactory.client:artifactory-java-client-services:+ since it is not good to point to a moving target (otherwise builds can break randomly and is hard to debug why)

  2. This issue cannot be resolve by excluding it because the dependency is embedded

// This will not work
compile(group: 'org.jfrog.artifactory.client', name: 'artifactory-java-client-services', version: '2.8.5') {
        exclude module: 'commons-io'
    }

Workaround: For now I will have to point to 2.8.4 until this issue gets fixed. The dependency for commons-io should be downloaded when you import artifactory-java-client-services and should not be embedded with it

image

deporcali avatar Sep 27 '19 20:09 deporcali

@deporcali, I don't recall the latest artifactory-client-java patch release included any dependencies changes. Do you know what caused this break?

eyalbe4 avatar Sep 27 '19 20:09 eyalbe4

The jar for artifactory-client-java 2.8.5 now seems to be a fat jar (look at the capture above).

The version of "commons-io" embedded inside the fat jar must conflict with the other version present on @deporcali 's classpath (2.4 according to the screenshot).

Since the build tool (Maven / Gradle) has no way to know the artifactory-client-java embeds "commons-io", it cannot detect a dependency version conflict and therefore cannot use the usual trick to fix the problem (that is, use the highest version of "commons-io" available on the classpath).

Hope the explanation makes sense.

The solution would be 1) not to use a fat jar or 2) the relocate the packages inside the fat jar to prevent the clash of classes.

fritaly avatar Sep 27 '19 20:09 fritaly

@eyalbe4 Yeah it seems that artifactory-java-services is using a FatJar now (see screenshot below for comparison). It does not even has the same content anymore. I feel like artifactory-java-services is not even needed.

image

deporcali avatar Sep 30 '19 15:09 deporcali

Related https://github.com/jfrog/artifactory-client-java/issues/261

danhyun avatar Oct 09 '19 19:10 danhyun

@deporcali @fritaly @danhyun, 2.8.6 is released - Feel free to upgrade. We'd appreciate you feedback for that.

yahavi avatar Oct 10 '19 09:10 yahavi