Jar Package Conflict resolution method

Objective

For the jar package conflict problem, we are often encountered by developers, when we use some of the jar package classes, methods, etc., or sometimes encounter some log system problems (refer to another article Jar package conflict caused by the log problem), we will encounter ClassNotFoundException, Run-time exceptions such as nosuchfieldexception,nosuchmethodexception, we will judge from experience that jar packages conflict. Solve the jar package conflict problem, everyone has a method, here I introduce my method for your reference.

Processing methods

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-ServerWar1.0-snapshot[info] +-Com.taobao.wlb:bis-CoreJar:1.0-Snapshot:compile[info] | \-Com.taobao.logistics:schedule-ClientJar:1.1.1:compile[info] | \-(Com.taobao.notify:notify-CommonJar:1.8.15:compile-omittedFor conflict with1.8.19.) [INFO] \-Com.taobao.notify:notify-tr-Clientjar:1.8.19 .26:compile[info] +-Com.taobao. notify:notify-common:jar:1.8.19.26:compile[info] \-com.taobao.< Span class= "hljs-string" >notify:notify-remoting:jar:1.8.19.26:compile[info] \-(com.taobao.< Span class= "hljs-string" >notify:notify-common:jar:1.8.19.26:compile-omitted for duplicate)            

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

Jar Package Conflict resolution method