search

jfrog / artifactory-client-java

Artifactory REST Client Java API bindings
Apache License 2.0
319 stars 153 forks source link

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

Closed deporcali closed 5 months ago

deporcali commented 5 years ago

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

eyalbe4 commented 5 years ago

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

fritaly commented 5 years ago

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.

deporcali commented 5 years ago

@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

danhyun commented 5 years ago

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

yahavi commented 5 years ago

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