依赖传递
参见：Maven依赖机制简介
总结：
一句话概括：当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖
依赖冲突
总结：
既然依赖可以传递，那么工程就能获取到依赖的所有版本。当传递的依赖有多个版本时，就产生了冲突
依赖选取
总结：
冲突是客观存在的，需要有策略能解决冲突。
Maven依赖选取原则
- 最短路径
- 最先声明
最短路径
依赖e的版本为1.2版本
最先声明
如果在工程A中，先声明对依赖b的依赖，由于依赖b依赖d的1.1版本，因此工程A会依赖d的1.1版本
冲突分析
不解决冲突，可能会出现ClassNotFoundException或NoSuchMethodException。如下所示：
分析方法
参见Maven提高篇系列之（五）——处理依赖冲突
Maven类包冲突终极解决小技若干
总结为：
使用
dependency:tree分析依赖使用
mvn dependency:tree -Dverbose查看更多信息，尤其conflict不想被其他信息干扰，添加
Dincludes或者Dexcludes来排除干扰，如下只显示asm:asm相关的信息：mvn dependency:tree -Dverbose -Dincludes=asm:asm
- mvn dependency:analyze?
如上图所示，curator-framework依赖curator-client的版本是2.12.0。但是根据依赖选取规则，选取的curator-client版本是2.7.1。这样curator-framework只能降级，使用2.7.1版本的curator-client。如果使用了只有在2.12.0中存在的方法，那么就会报错。
绝大多数情况下，高版本都会兼容低版本。因此，使maven选取高版本的依赖，是比较好的做法。
解决冲突
参见：Maven 依赖管理
总结
- 缩短指定版本的路径
- exclude掉不想要的版本
- 将依赖声明为optional
根据依赖选取策略，snappy-java的1.1.4版本会被选取。这个明显高于其他的1.1.1.6和1.1.2.6版本。一般情况下，高版本会兼容低版本，因此这种情况通常不会出问题。
