Maven依赖

一、传递性依赖

　　传递性依赖也就是隐式依赖，能够极大的简化项目依赖的管理，可是也会致使一些难以排查的问题。

　　如：当项目引入一个第三方依赖，因为某些缘由，依赖了另一个类库的SNAPSHOT版本，那么这个SNAPSHOT就会成为当前项目的传递性依赖，而SNAPSHOT依赖的不稳定性会直接影响大年的项目，此时须要手动排除该传递性依赖，并在当前项目中声明某个该类库的正式发布版本，或者是你直接想要替换某个传递性依赖。

　　替换传递性依赖：<exclusions></ exclusions>

　　

　　　　上述图片，项目a依赖项目b，因为某些缘由不想引入项目c，而本身显示声明多项目c1.1.0版本的依赖，逻辑图以下：

　　　　　　

二、归类依赖

　　简而言之，当咱们依赖一整套组件时，如spring，咱们一般是依赖他们各个组件的同一个版本，此时因为每一个依赖都须要指定版本，重复性工做太多而且一旦依赖版本升级，修改也比较繁琐，因此经过归类，咱们能够经过maven的properties属性，在一个位置指定具体版本，其余具体依赖直接获取这个属性便可。

　　pom文件指定属性：

　　

　　pom文件具体依赖直接获取

　　　　

三、优化依赖

　　3.一、mvn  dependency:list :查看当前项目的已解析依赖

　　3.二、mvn  dependency:tree :查看当前项目的依赖树

　　3.三、mvn  dependency:analyze :分析当前项目的依赖

　　这里会出现两种常见说明：

　　　　Used undeclared dependencies found:未显示声明但已使用的依赖（传递性依赖）

　　　　Unused delared dependencies found:已显示声明但未使用的依赖（因为此mvn命令只是分析主代码和测试类，并不全面，因此对于这条分析结果，须要自行排查此依赖

　　　　是否真的没有用，再决定是否删除不可直接删除）

四、依赖冲突与解决

   依赖冲突解决资源来自：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。