1、传递性依赖
传递性依赖也就是隐式依赖，可以极大的简化项目依赖的管理，但是也会导致一些难以排查的问题。
如：当项目引入一个第三方依赖，由于某些原因，依赖了另外一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT依赖的不稳定性会直接影响大年的项目，此时需要手动排除该传递性依赖，并在当前项目中声明某个该类库的正式发布版本，或者是你直接想要替换某个传递性依赖。
替换传递性依赖：<exclusions></ exclusions>
上述图片，项目a依赖项目b，由于某些原因不想引入项目c，而自己显示声明多项目c1.1.0版本的依赖，逻辑图如下：
2、归类依赖
简而言之，当我们依赖一整套组件时，如spring，我们通常是依赖他们各个组件的同一个版本，此时由于每个依赖都需要指定版本，重复性工作太多并且一旦依赖版本升级，修改也比较繁琐，所以通过归类，我们可以通过maven的properties属性，在一个位置指定具体版本，其他具体依赖直接获取这个属性即可。
pom文件指定属性：
pom文件具体依赖直接获取
3、优化依赖
3.1、mvn dependency:list :查看当前项目的已解析依赖
3.2、mvn dependency:tree :查看当前项目的依赖树
3.3、mvn dependency:analyze :分析当前项目的依赖
这里会出现两种常见说明：
Used undeclared dependencies found:未显示声明但已使用的依赖（传递性依赖）
Unused delared dependencies found:已显示声明但未使用的依赖（由于此mvn命令只是分析主代码和测试类，并不全面，所以对于这条分析结果，需要自行排查此依赖
是否真的没有用，再决定是否删除不可直接删除）
4、依赖冲突与解决
依赖冲突解决资源来自：http://www.cnblogs.com/ygj0930/p/6628429.html
依赖冲突：一个项目A，通过不同依赖传递路径依赖于X，若在不同路径下传递过来的X版本不同，那么A应该导入哪个版本的X包呢？
冲突解决方案：
1：如果依赖路径的长度不同，则“短路优先”：
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
2：依赖路径长度相同情况下，则“先声明优先”：
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则在项目A的<depencies></depencies>中，E、F哪个在先则A依赖哪条路径的X。
