mvn dependency:list可以列出来项目中解决的依赖；
mvn dependency:tree可以以树形的形式展示解析的依赖。为了查找代码中的jar包是通过哪一个依赖引入的，这个命令大有帮助。当我们有大量的依赖需要查看时，则可以把结果重定向到文件，然后搜索。或者也可以使用一个-Dincludes=groupId:artifactId参数指定要查找的jar包。-Dincludes使用最左匹配原则，可以只指定groupId，但是不能智志定artifactId。
例子：helloworld引入data依赖，data引入了junit依赖。
mvn dependency:list:
[INFO] The following files have been resolved:
[INFO] org.hamcrest:hamcrest-core:jar:1.3:compile
[INFO] com.liyao:data:jar:1.0:compile
[INFO] junit:junit:jar:4.12:compile
mvn dependency:tree:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ helloworld ---
[INFO] com.liyao:helloworld:jar:1.0-SNAPSHOT
[INFO] \- com.liyao:data:jar:1.0:compile
[INFO] \- junit:junit:jar:4.12:compile
[INFO] \- org.hamcrest:hamcrest-core:jar:1.3:compile
现在要查找junit依赖：
可以mvn dependency:tree -Dincludes=junit或者mvn dependency:tree -Dincludes=junit:junit
[INFO] com.liyao:helloworld:jar:1.0-SNAPSHOT
[INFO] \- com.liyao:data:jar:1.0:compile
[INFO] \- junit:junit:jar:4.12:compile
返回了junit的依赖树。
这里其实出现了一个概念：传递依赖。项目汇总引入了jar包A，A本身又引入了依赖B。那么项目其实传递依赖了B。传递依赖会带来一个问题，依赖冲突。项目最终会有两条或者多条不同的依赖树到达同一个jar包，但是版本不同。maven最终只会引入一个。这可能会导致问题，S->A->B, S->C->B 假设存在这样的两条依赖，最终都是B，但是版本不同，不同版本的B提供的api也不同，这时，无论最终导入哪一个版本的B，另一条依赖都无法编译成功，这可能导致问题排查很难。
那么maven会选择哪一个版本？
两个原则。
第一： 路径最短者优先；
第二：如果路径相同，先声明者优先；
还是开篇的那个例子，junit原本是在data包里传递引入的，版本是4.12。这时在helloworld项目中也加入一个条4.8.1的junit依赖，在运行tree命令：
[INFO] com.liyao:helloworld:jar:1.0-SNAPSHOT
[INFO] +- com.liyao:data:jar:1.0:compile
[INFO] \- junit:junit:jar:4.8.1:compile
说明引入了helloworld中定义的junit依赖，与原则一相符。
再在helloworld引入service模块，service引入一个4.8的junit。通过试验发现，junit的版本与data和sevice声明的顺序有关，这与原则二一致。