MAVEN is a "step-by-step" for beginners because it's all-encompassing and profound, because when you're new, you're as confused as a strange visitor entering the forest.
MAVEN is the "true love Formula" for the veteran, because it is omnipotent, like Blade, using MAVEN to develop, such as drinking wine such as Yue beauty.
Maven the most painful thing for a novice is the conflict between packages, because of Maven's dependency transitivity, when you introduce a dependency class, the dependency class behind it awash.
give me a chestnut .
A relies on B and C, and B is dependent on X, Y, and C depends on X, M, and a dependency package of B and C is also introduced under X,Y,M (typically, MAVEN can control delivery dependencies in several ways, such as <scope>).
Here's a special note that B and C depend on X at the same time, assuming B depends on the 1.0 version of X, and C depends on the 2.0 version of X, whether a depends on the X 1.0 or the 2.0 version.
This depends on the loading order of the ClassLoader, assuming that ClassLoader first load x_1.0, and it will not load x_2.0, if a just want to use x_2.0 it, the murder of such an encounter.
The kick I used to whirl.
First axe: Find out where the ghosts of the passing dependencies are.
Dependency:tree is the photo of the demon, pom.xml with it, all the transitive dependence will be nowhere to hide, and will be in a hierarchical tree way, very intuitive.
The following is an output after executing dependency:tree:
Reference
[INFO]---maven-dependency-plugin:2.1:tree (default-cli) @ euler-foundation---
[INFO] Com.hsit:euler-foundation:jar:0.9.0.1-snapshot
[INFO] +-Com.rop:rop:jar:1.0.1:compile
[INFO] | +-Org.slf4j:slf4j-api:jar:1.7.5:compile
[INFO] | +-Org.slf4j:slf4j-log4j12:jar:1.7.5:compile
[INFO] | +-Log4j:log4j:jar:1.2.16:compile
[INFO] | +-Commons-lang:commons-lang:jar:2.6:compile
[INFO] | +-Commons-codec:commons-codec:jar:1.6:compile
[INFO] | +-Javax.validation:validation-api:jar:1.0.0.ga:compile
[INFO] | +-Org.hibernate:hibernate-validator:jar:4.2.0.final:compile
[INFO] | +-Org.codehaus.jackson:jackson-core-asl:jar:1.9.5:compile
[INFO] | +-Org.codehaus.jackson:jackson-mapper-asl:jar:1.9.5:compile
[INFO] | +-Org.codehaus.jackson:jackson-jaxrs:jar:1.9.5:compile
[INFO] | +-Org.codehaus.jackson:jackson-xc:jar:1.9.5:compile
[INFO] | \-Com.fasterxml.jackson.dataformat:jackson-dataformat-xml:jar:2.2.3:compile
[INFO] | +-Com.fasterxml.jackson.core:jackson-core:jar:2.2.3:compile
[INFO] | +-Com.fasterxml.jackson.core:jackson-annotations:jar:2.2.3:compile
[INFO] | +-Com.fasterxml.jackson.core:jackson-databind:jar:2.2.3:compile
[INFO] | +-Com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.2.3:compile
[INFO] | \-Org.codehaus.woodstox:stax2-api:jar:3.1.1:compile
[INFO] | \-Javax.xml.stream:stax-api:jar:1.0-2:compile
Just bragging about dependency:tree, I used the "Nowhere to hide", in fact, sometimes you will find that simply using dependency:tree often can not see all the transmission dependencies. But if you really want to see all of it, you have to add a-dverbose parameter, then it must be the most complete.
All of them, but there are too many things to show, Dizzy, there is no good method. Of course, plus dincludes or dexcludes say you like or hate, Dependency:tree will help you filter out:
Reference Dincludes=org.springframework:spring-tx
Filter string use GroupId:artifactId:version way to filter, can not write full, such as:
Java Code MVN dependency:tree-dverbose-dincludes=asm:asm
It's going to be out. ASM relies on packet profiling information:
Reference
[INFO]---maven-dependency-plugin:2.1:tree (default-cli) @ ridge-test---
[INFO] Com.ridge:ridge-test:jar:1.0.2-snapshot
[INFO] +-Asm:asm:jar:3.2:compile
[INFO] \-Org.unitils:unitils-dbmaintainer:jar:3.3:compile
[INFO] \-Org.hibernate:hibernate:jar:3.2.5.ga:compile
[INFO] +-Cglib:cglib:jar:2.1_3:compile
[INFO] | \-(asm:asm:jar:1.5.3:compile-omitted for conflict with 3.2)
[INFO] \-(asm:asm:jar:1.5.3:compile-omitted for conflict with 3.2)
[INFO]------------------------------------------------------------------------
There is a direct dependency on ASM (asm:asm:jar:3.2) and there is a dependency (asm:asm:jar:1.5.3) that passes into it.
Second axe: Remove unwanted transfer dependencies
Assuming that we do not want asm:asm:jar:1.5.3 to appear, according to the analysis, we know that it was introduced through org.unitils:unitils-dbmaintainer:jar:3.3, So find this dependency in pom.xml and make other adjustments:
XML code <dependency> <groupid>org.unitils</groupid > <artifactId>unitils-dbmaintainer</artifactId> <version>${unitils.version}</version> <exclusions> <exclusion> <artifactid>dbunit</ artifactid> <groupid >org.dbunit</groupId> </exclusion> <!-- This is the piece we want to add --> <exclusion> <artifactid>asm</artifactid> <groupId>asm</groupId> </exclusion> </exclusions> </dependency>
Again, you can see that the delivery dependency is gone:
XML code [INFO] [INFO]---maven-dependency-plugin:2.1:tree (default-cli) @ ridge-test---[info] com.ridge:ridge-test: Jar:1.0.2-snapshot [INFO] \-asm:asm:jar:3.2:compile [INFO]------------------------------------------------------- -----------------[INFO] BUILD SUCCESS
Third axe: Viewing the jar package from the source of the run-time class
