Maven依赖

一：依赖范围

Maven在编译项目主代码的时候需要使用一套classpath。其次，在编译和执行测试的时候会使用另外一套classpath。最后，实际运行Maven项目的时候，又会使用一套classpath。

所谓的依赖范围就是用来控制依赖与这三种classpath（编译、测试、运行）的关系，Maven有以下几种依赖范围：

• compile：编译依赖范围。如果没有指定，默认使用该依赖范围。使用此依赖范围时，对于编译、测试、运行都有效。例如：spring-core，编译、测试、运行时都需要使用该依赖。
• test：测试依赖范围。只对测试classpath有效。例如：JUnit，它只在编译测试代码以及运行测试的时候才需要，编译和运行classpath时无法使用此依赖。
• provided：已提供依赖范围。对于编译和测试时有效，但在运行时无效。例如：servlet-api，编译和测试项目的时候需要该依赖，但运行时，由于容器已经提供，就不需要Maven重复的引入。
• runtime：运行时依赖。编译时无效，对于测试和运行有效。例如：JDBC驱动实现，编译时只需要JDK提供的JDBC接口，只有在执行测试和运行时才需要实现上述接口的具体JDBC驱动。
• system：系统依赖范围。同provided。使用该依赖时必须通过systemPath元素显式地指定依赖文件路径。主要用于依赖本地的、且Maven仓库之外的类库文件。例如：

<dependency>
　　<groupId>javax.sql</groupId>
　　<artifactId>jdbc-stdext</artifactId>
　　<version>2.5</version>
　　<scope>system</scope>
　　<systemPath>${spath}/lib/test.jar<systemPath>
</dependency>

二：传递依赖和依赖范围

当我们依赖一个a.jar时，如果a.jar依赖b.jar，那么只需要早pom中声明对a.jar的依赖即可，b.jar会被Maven自动加载进来。

例如：有一个org.springframework:spring-core:2.5.6的依赖，而实际上spring-core也有它自己的依赖，它依赖commons-logging。有了传递依赖机制，在使用spring-core时不需要考虑它依赖了什么。Maven会自动解析。

依赖范围在传递依赖时会略有变化

当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；

当第二直接依赖的范围是test的时候，依赖不会得以传递；

当第二直接依赖的范围是provided的时候，只传递第一直接依赖范围也为provi的依赖，且范围为provided；

当第二直接依赖的范围是runtime的时候，传递性的依赖范围与第一直接依赖的范围一致，但compile例外，此时传递依赖范围为runtime；

三：依赖调解

• 原则一：路径最近者优先。例如：A ->B ->C ->X(1.0) 同时 A ->D ->X(2.0)，很显然X(2.0)路径更短，会被解析使用。
• 原则二：第一声明者优先。在依赖长度相等情况下，解析在pom中依赖声明中顺序考前的。例如：A ->B ->X(1.0) 同时 A ->D ->X(2.0)。如果B在D之前声明，那么X(1.0)会被解析。

除以上两种原则外，还可以手动排除，例如：A ->B ->X(1.0)同时A ->X(2.0)。如果项目A希望加载X(2.0)可做如下声明，通过<exclusion>元素来显式排除。

<dependency>
　　<groupId>com.xxx.xx</groupId>
　　<artifactId>xx-B</artifactId>
　　<version>2.5</version>
　　<exclusions>
　　　　<exclusion>
　　　　　　<groupId>com.xx</groupId>
　　　　　　<artifactId>project-X</artifactId>
　　　　</exclusion>
　　</exclusions>
</dependency>
<dependency> 
　　<groupId>com.xxx.xx</groupId>
　　<artifactId>project-x</artifactId>
　　<version>2.0</version>
</dependency>