5 Maven-依赖详解

5.1 依赖的配置：

所有的坐标都是在 dependenciesy元素中，其中包含了多个dependency子元素。每个依赖可以包含的元素有：

groupId、artifactId、version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。
type：依赖的类型，对于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar。
scope：依赖的范围。
optional：标记依赖是否可选。
exclusions：用来排除传递性依赖。   


5.2依赖的范围：
依赖的范围就是用来控制依赖与三种classpath（编译classpath、测试classpath、运行classpath）的关系。

compile：编译依赖范围。如果没有指定，就会默认使用该范围。使用此范围的Maven依赖，对于编译、测试、运行三种calsspath都有效。

test：测试依赖范围。使用此范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。如 JUnit工             具。

provided：已提供依赖范围。对于编译和测试classpath都有效，但是运行时无效。

runtime：运行时依赖范围。对于测试和运行classpath有效，但在编译主代码时无效。典型的列子是JDBC驱动实 现，项目主代码的编译只需要JDK提                 供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的。具体JDBC驱动。

system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素                 显式地指定依赖文件的路径。   

5.2传递性依赖：
当我们在使用Spring Framework的时候需要手动下载相关依赖，而在实际使用的时候还要根据出错信息，或者查询相关文档，加入需要的其他依赖。Maven的传递性依赖机制可以很好的解决这一问题。有了传递性依赖机制，在使用 Spring Framework的时候就不同考虑它的间接依赖，以传递性依赖的形势引入当前的项目中。   


5.3依赖调解：
Maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不需要考虑这些直接依赖会引入什么传递性依赖。但是，当传递性造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。
  原则一：A->B->C->X(1.0)、A->D->X(2.0)。路劲最近者优先。即使用X(2.0)
  原则二：A->B->Y(1.0)、A->B->Y(2.0)。第一声明者优先。即Y(1.0)


5.4可选依赖
假设： A->B、B->X(可选)、B->Y(可选)。根据传递性依赖的定义，如果有这三个依赖的范围都是compile，那么X、Y就是A的compile范围传递性依赖。然而，由于X、Y是可选依赖，依赖将不会得以传递。换句话说，X、Y将不会对A有任何影响。


5.5排除依赖
假设，项目A依赖项目B，项目B依赖项目C。但是由于一些原因不想引入传递性依赖C，而是自己显式地声明对于项目C版本的依赖。代码中使用exclusions元素声明排除依赖性，exclusions可以包含多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是只需要groupId和artifactId，而不需要version元素。


5.6优化依赖

mvn dependency:list    
    Maven会自动解析所有项目的直接依赖和传递性依赖，并且根据规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖。如下图：

mvn dependency:tree
通过依赖树就能很清楚地看到某个依赖时通过哪条传递路径引入的。 如下图：

mvn dependency:analyze

可以分析当前项目的依赖

备注：在ecplipse中直接把 mvn去掉。在cmd窗口中需要 mvn