Develop Reference

How to resolve external dependency conflict in gradle

I am getting following conflicts for okio library in my sprint boot project.
I am not not sure how to read this. Specifically:
What does conflict actually mean here. What is conflicting with what?
Why is 1.6.0 is conflicting with 1.6.0
What does Scopes mean (6 scopes , 4 scopes) etc..
How do I resolve this in my gradle project. Current in my build.gradle I have
implementation "org.apache.commons:commons-vfs2:2.9.0"
implementation 'io.fabric8:kubernetes-client:6.3.1'
My server fails to start with a NoSuchFieldError within a class in Okio library. How can I go about resolving this? None of this is my direct code issue is happening in the okio which is the transitive dependency of above two libraries.

It is having same library but two version of it on classpath, so at run time any one would be picked.
And if the version has some breaking changes, it won't work. You have to put a constraint to have only one version.
You can refer to How Gradle handles conflicts? for more information.

Maven pull an old version of a transitive dependency

I've written a library I've written that depends upon Guava version 20.0 (the last version that is compatible with JDK 1.7)
I've then written an application that uses that library and also uk.org.lidalia:slf4j-test:1.2.0 (with test scope). slf4j-test has a dependency on version 14.0.1 of Guava.
My problem is that my application is seeing two different versions of Guava as transitive dependencies and picks the OLDER version. Now when I call certain methods in my Library I get Class or Method not found exceptions.
I can (and have) excluded Guava as a dependency of slf4j-test, which fixes the problem for now, but the problem will return if I introduce another dependency which uses Guava.
So my question is: Why would Maven pick the older version of a dependency and how do I always make it pick the latest versions.

You cannot force Maven to always pick the latest version. But there are several things you can do:
If you declare the dependency in your own pom, this version always wins. So if you have a dependency on guava 20.0 in your pom, you will get exactly this.
If this is not suitable, you can put an entry into dependencyManagement which sets the version for guava. This will overwrite all transitively set versions (like the 14.0.1 in your example).
The Maven enforcer plugin has a rule that makes sure that all dependencies are evaluated to the latest version - but it does not pick that latest version, it only fails the build if it was not chosen. Then you need to choose it yourself by applying method (1) or (2) above.

How can I prevent code from using wrong version of some dependency?

I have a project which depends on a JAR file. The version of this JAR changes often and we are having a hard time trying to ensure we are using the correct one. It is also causing problems when investigating bugs: which version of JAR contains the bug. Some programmers may forget to update corresponding dependencies and include 2 versions of this JAR inside the project, so that an old version may be found by the classloader.
A question is how to account for this issue.
I have a following plan:
1) When an error occurs log the JAR name I am working with to ensure it is a correct version. I plan to use something like
this.getClass().getResource(someResourceINeedFromThatJar).getFile()
2) I can write a test to account for this. But I don't know how I can run a test AFTER the package phase of my Maven build
3) Maybe you can suggest something else for this?

Well, We have same scenario and solved issue by using maven dependencyManagement
It does two things.
Set a default version for dependencies in submodules/child projects
override the version of transitive dependencies
it does override a specified value in a transitive dependency.
The enforcer plugin does not ignore the dependencyManagement. But is unable to recognize the discrepancy since the transitive dependency's version was altered before it went to work.
Here is a nice article : You can go through it:
http://andydennie.com/2012/08/02/maven-enforcer-plugin-vs-dependencymanagement/
And another source: http://maven.apache.org/enforcer/maven-enforcer-plugin/

IBM SBT SDK 1.1.0 (Java) and Apache xerces

I am adding IC integration with IBM SBT SDK (Java) into an existing project which still uses xerces 2.4.0 (as of March 2009).
Using IBM SBT SDK 1.0.x did not cause any problems here, but the XML serialization implementation of 1.1.0 completely relies on org.w3c.xml.ls.DOMImplementationLS and such stuff which was introduced after moving xerces to "xercesImpl" about 2004.
However the project contains much code working with XML based on xerces and xml-apis, and it looks dangerous to move too fast to "more current" versions of these libraries. Thus I want to move "no further than absolutely required".
Thanks to maven no one can directly see which version of any artifact is loaded if it is not directly referenced in the pom.xml. Thus my question:
Which version of xercesImpl is "really" required by IBM SBT SDK 1.1.0? 2.4.0 is not sufficient, as some methods used in the SBT SDK are not yet implemented there...

xerces version in the dependency would be 2.9.0; looking at the DOMUtil.java#loadDriver() class however there are workarounds to avoid the SBTK to use xerces altogether:
if your container allows to control the classpath tree, shadowing the xerces library from the toolkit will have it default to some other driver. In alternative you can provide your own XercesDriver class compatible with old xerces versions and leverage the classloader to have it loaded in place of ours.
if you are in a osgi container you can also make sure the host application manifest declares a dependency to a version <=2.4.0 and load both xerces versions letting the container fix the dependencies for you
anyway, to answer the question, using:
mvn dependency:list
I get version 2.9.0 for xerces:
The following files have been resolved:
com.ibm.sbt:com.ibm.commons:eclipse-plugin:9.0.0:provided
p2.eclipse-plugin:javax.servlet:jar:3.0.0.v201112011016:system
p2.eclipse-plugin:javax.xml:jar:1.3.4.v201005080400:system
p2.eclipse-plugin:org.apache.xalan:jar:2.7.1.v201005080400:system
p2.eclipse-plugin:org.apache.xerces:jar:2.9.0.v201101211617:system
p2.eclipse-plugin:org.apache.xml.resolver:jar:1.2.0.v201005080400:system
p2.eclipse-plugin:org.apache.xml.serializer:jar:2.7.1.v201005080400:system
p2.eclipse-plugin:org.eclipse.core.contenttype:jar:3.4.200.v20120523-2004:system
p2.eclipse-plugin:org.eclipse.core.jobs:jar:3.5.300.v20120912-155018:system
p2.eclipse-plugin:org.eclipse.core.runtime:jar:3.8.0.v20120912-155025:system
p2.eclipse-plugin:org.eclipse.equinox.app:jar:1.3.100.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.equinox.common:jar:3.6.100.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.equinox.preferences:jar:3.5.1.v20121031-182809:system
p2.eclipse-plugin:org.eclipse.equinox.registry:jar:3.5.200.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.osgi:jar:3.8.2.v20130124-134944:system

Preferring the latest jar in a sea of dependencies (java)

I have a large Ivy project, and Ive noticed that my code, which run well in eclipse, cause a compile error when run in ant. I've narrowed the problem down to the following line :
FileUtils.write(...).
This line fails - during compilation --- the method is simply not found. Obviously, my code is dependant on apache's commons-io library. And its quite clear that the current commons-io has this method.
http://commons.apache.org/io/apidocs/org/apache/commons/io/FileUtils.html
So what gives ?
I am pretty sure this is related to my ivy.xml -> the eclipse compiler is luckily (or smartly) using the newest possible version of commons-io , whereas my ivy.xml is using an older version which lacks this method.
Most important of all to not here is that ant is clearly using a different version of this jar.
So - my question is :
1) How can I tell ant / ivy to preferentially compile my code with the latest versions of libraries i specify ? I'm assuming that some of the dependencies in my lib/ may depend on older versions of commons-io .....
Also :
2) In this context, any hints about what to worry about regarding the how the classloader deals with duplicates in a multi-jar-dependent project would also be helpful to me ...

Dependency Reporting
I would suggest that you first add the generation of an ivy dependency report into your build, using the report task.
An example of this task is included in the following answer:
What is the Ivy equivalent of Maven's versions:display-dependency-updates?
This will tell you what versions of what jars are being used. Normally, ivy will use the version you specify in the ivy.xml file, however, another module might depend on a more recent version. Ivy's default behaviour is to always favour the most recent version of a Maven module.
Retrieve the latest dependency
If you want ivy to always prefer the latest version of a particular library then declare the dependency as follows:
<dependency org="commons-io" name="commons-io" rev="latest.release"/>

Ivy has a feature called Fixed and Dynamic Revisions.
You can set the version/revision of any artifact to latest-status like
rev="latest.integration" --> for development released
rev="latest.release" --> for released versions
Ivy takes the version with the highest version(you have specified) and omits all libraries with lower versions, so that you only have one lib in the ivy classpath (have a look at the resolution report, run ant -v (verbose mode))., which avoids having duplicate jars with conflicting versions.
This might be worth checking out, maybe you just have an old version defined in one of your ivy files.
As to the second point:
The classloader takes the class, that happens to be first in the classpath(or the jar that is first in the classpath). So mixed versions of the same lib, could behave differently on any system, depending on how the classpath is constructed.