Maven 的依赖范围、依赖传递以及排除依赖

1. 依赖范围：

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.10</version>
    <scope>test</scope>
 </dependency>

如上代码中，<scope>标签用于指定当前插件的依赖范围；这里指定<scope>标签的值为test，即指定该构件只存在于测试环境中。

在开发中我们把第三方jar放入到classpath中，就能够调用第三方的类和方法。

maven有三种classpath分别是：编译、测试、运行； 

2. scope的取值：

  (1). compile 默认的范围，编译测试运行都有效。

  (2). provided 编译和测试时有效，最后是在运行的时候不会被加入。官方举了一个例子。比如在JavaEE web项目中我们需要使用servlet的API，但是呢Tomcat中已经提供这个jar，我们在编译和测试的时候需要使用这个api，但是部署到tomcat的时候，如果还加入servlet构建就会产生冲突，这个时候就可以使用provided。 

  (3). runtime 在测试和运行时有效。

  (4). test 在测试时有效。

  (5). system 与本机系统相关联，可移植性差。编译和测试时有效。

  (6). import 导入的范围，它只在使用dependencyManagement中，表示从其他pom中导入dependecy的配置。

3. 依赖传递：

在实际开发过程中，我们通常会封装maven构件以供在其他构件/模块中进行使用；在使用我们自定义的构件时，自定义构件中的依赖也会被传递过来。

例如，有Maven项目A，项目B依赖A，项目C依赖B。那么我们可以说 C依赖A。也就是说，依赖的关系为：C—>B—>A；那么我们执行项目C时，会自动把B、A都下载导入到C项目的jar包文件夹中。这就是依赖的传递性。

4. 排除依赖传递：

 如上，C—>B—>A。加入现在不想执行C时把A下载进来，那么我们可以用 <exclusions>标签。

<dependencies>
    <dependency>
        <groupId>B</groupId>
        <artifactId>B</artifactId>
        <version>0.0.1</version>
         <exclusions>
            <exclusion>
              <!--被排除的依赖包坐标-->
              <groupId>A</groupId>
              <artifactId>A</artifactId>
              <version>0.0.1</version>
            </exclusion>
         </exclusions>
    </dependency>
</dependencies>

 5. 依赖冲突及解决：

依赖冲突：一个项目A，通过不同依赖传递路径依赖于X，若在不同路径下传递过来的X版本不同，那么A怎么确定导入哪个版本的X包呢？

例如，项目A同时依赖构件01、构件02、......甚至多个构件；而在构件01和构件02中分别直接依赖log4j的两个不同版本时，项目A如何确定要导入的log4j的版本。

在Maven项目中，对于此类现象的处理原则是：

(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。