Maven实战_依赖

 

（一） 依赖配置声明

包含以下的一些元素：

<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)就会被解析使用。