maven实战(03)_依赖

（一） 依赖配置声明

包含以下的一些元素：

 <project>
     ...
     <dependencies>
         <dependency>
             <groupId>...</groupId>
             <artifactId>...</artifactId>
             <version>..</version>
             <!-- 依赖的类型，不写就默认为jar -->
             <type>...</type>
             <!-- 依赖的范围 -->
             <scope>...</scope>
             <!-- 标记依赖是否可选 -->
             <optional>...</optional>
             <!-- 用来排除传递性依赖 -->
             <exclusions>
               <exclusion>
                 ...
               </exclusion>
               ...
             </exclusions>
         </dependency>
         ...
     </dependencies>
 </project>

举个栗子：

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

（二） 依赖范围

表： 依赖范围与classpath的关系

依赖范围 （Scope）	对于编译 classpath有效	对于测试 classpath有效	对于运行时 classpath有效	例子
compile	Y	Y	Y	spring-core
test	-	Y	-	JUnit
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	JDBC驱动实现
system	Y	Y	-	本地的，Maven仓库 之外的类库文件

 compile编译依赖范围

【不指定就默认使用此依赖范围】，使用此依赖，对于编译，测试，运行三种classpath都有效；

test 测试依赖范围

表示该依赖只对测试有效，
换句话说，测试代码中的import JUnit代码是没有问题的。
但在主代码中用import JUnit，编译不会通过 。
依赖范围默认为compile,表示该依赖对主代码和测试代码都有效。

一个典型的单元测试包含了三个步骤：

1 准备测试类及数据；

2 执行要测试的行为；

3 检查结果。

测试用例编写完毕之后，就可以调用mave执行测试，在项目根目录下运行:mvn clean test

provided 已提供依赖范围

【对于编译和测试classpath有效，在运行时无效】

(三) 依赖调解

项目A有这样的依赖关系：A -> B -> C -> X(1.0) , A -> D -> X(2.0)

X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？

两个版本都解析是不对的，因为那会造成依赖重复，因此必须选择一个。

maven依赖调解的第一原则是：路径最近者优先。该例子中X（1.0）的路径长度为3，而X（2.0）的路径长度为2，因此X（2.0）会被解析使用。

但是，比如这样的依赖关系：A -> B  -> Y(1.0) , A -> C -> Y(2.0) ，

Y（1.0）和Y（2.0）的依赖路径长度是一样的，都为2。

maven依赖的第二原则是：第一声明者优先（在Maven2.0.9版本之后）

如果B的依赖声明在C之前，那么Y(1.0)就会被解析使用。