How to resolve package conflict issues

Here is an example of a package conflict:

You quoted 2 three-party packages A.jar and B.jar, A.jar also quoted a c.jar, assuming C.jar version number is version-1, B.jar also refers to C.jar, assuming that C.jar in A.jar AR is a higher version, recorded as Version-2, a class in B.jar refers to method A () in C.jar class ClassA, and the method exists only in a higher version of C.jar (Version-2) class ClassA, and does not exist C.ja R (version-1) in the class ClassA.

When the system compiles and loads, the system may compile the load C.jar (version-1), or it may compile the load C.jar (version-2), when the compilation load C.jar (version-2), because many jar packages support backwards compatibility, that is, a high version compatible with the lower version, So whether A.jar calls C.jar or B.jar calls C.jar generally does not have a problem. However, if the compile-loaded class ClassA in C.jar (version-1) is applied at this point, then B.jar call Method A () will report the above error, because the method a () function exists only in the higher version of C.jar, while the system compiler loads the Low version of C.jar.

the common exception for Jar package conflicts is that the class (java.lang.ClassNotFoundException) cannot be found, the specific method (Java.lang.NoSuchMethodError) is not found, the field error ( JAVA.LANG.NOSUCHFIELDERROR) or class error (Java.lang.LinkageError).

The common workarounds are as follows:

1, the first method is to play the project files rely on the tree, will be based on the jar package depends on the situation to determine whether the same jar is dependent on multiple versions, if the problem is identified, directly exclusion the wrong jar package can be;

2, if by looking at the dependency tree can not determine the specific conflict jar package, you can use the method of adding JVM parameters to start the program, the class loaded specific jar information printed out;-verbose:class;

3, after the above steps can solve the jar package conflict, the specific problem to be specific analysis, when the problem is not reproducible, the above methods will not be effective.

How to arrange the package:

<Dependency>  <groupId>Com.know.diamond</groupId>  <Artifactid>Diamond-sdk</Artifactid>  <version>2.0.5</version>  <Exclusions>      <exclusion>        <groupId>Com.google.collections</groupId>         <Artifactid>Google-collections</Artifactid>   </exclusion>   </Exclusions></Dependency>

When encountering a jar package conflict, we first determine which jar package is conflicting, which is easy to see which of the classes or methods we call belong to which jar package. And then we're going to find the conflict, I'm using the command here.

mvn dependency:tree -Dverbose -Dincludes=<groupId>:<artifactId>

Fill in the jar package of GroupID and Artifactid, can only one, but the middle of the colon not less, so it will output a dependency tree, and is only a dependency tree containing the jar package, so that those places rely on the jar package version is clear.
For example, the Notify-common package in my project has a conflict, and we use the command
mvn dependency:tree -Dverbose -Dincludes=:notify-common
Get dependency Tree Output

[INFO] com.taobao.wlb:bis-server:war:1.0-snapshot[info] +-com.taobao.wlb:bis-core:jar:1.0-snapshot:compile[info] |  \-Com.taobao.logistics:schedule-client:jar:1.1.1:compile[info] |     \-(com.taobao.notify:notify-common:jar:1.8.15:compile-omitted for Conflict with 1.8.19.26) [INFO] \- Com.taobao.notify:notify-tr-client:jar:1.8.19.26:compile[info]    +-Com.taobao.notify:notify-common:jar : 1.8.19.26:compile[info]    \-Com.taobao.notify:notify-remoting:jar:1.8.19.26:compile[info]       

Look at all the leaf nodes in the dependency tree is all the Notify-common package, we can see that we rely on the Bis-core in the Schedule-client package, it relies on a Notify-common package, The version is 1.8.15, and the fourth line is followed by a hint that the package is in conflict with the other packages.
- omitted for conflict with 1.8.19.26)。 And our system depends on the Notify-tr-client package depends on the version is 1.8.19.26, so we know it is here conflict, in the Pom ruled out dependence, OK.

Description

Here we make a brief description of the commands we execute.
mvn dependency:tree -Dverbose -Dincludes=<groupId>:<artifactId>
The first part mvn dependency:tree is the analysis command that MAVEN relies on to analyze the dependencies of our project and output the project dependency tree.

The second part -Dverbose of the role is to add a verbose environment variable, the role is to analyze the project depends on the output details, so that all the references in the project will be output, including all the indirect references, there will be many, we just need to find, so we need a third parameter.

The third part -Dincludes=<groupId>:<artifactId> of the role is to filter, only contains the dependencies we want to rely on, excluding other unwanted, tree-dependent all leaf nodes is our search for the dependency package. The GroupID and Artifactid can only be filled in one, in order to ensure the accuracy of the general will fill two (not including angle brackets when filling).

Other methods:

1, for the MAVEN project, my approach is to use Eclipse to solve, point open pom.xml, switch to hierarchy dependency, the upper right corner of the search for the corresponding package, you can clearly see the conflict version

2. You can use idea, right-click in Pom.xml to select diagrams-"Show dependencies

3. MVN dependency:tree-dverbose > Tree.log
Direct output of conflicting jar files

How to resolve package conflict issues