Maven简介(六)——Dependency

7      Dependency介绍

http://elim.iteye.com/category/269897

7.1     依赖的传递性

当项目A依赖于B,而B又依赖于C的时候,自然的A会依赖于C,这样Maven在建立项目A的时候,会自动加载对C的依赖。

依赖传递对版本的选择

假设A依赖于B和C,然后B依赖于D,D又依赖于E1.0,C直接依赖于E2.0,那么这个时候A依赖的是E1.0还是E2.0,还是这两个都依赖呢?两个都依赖是肯定不行的,因为它们可能会有冲突的地方。这个时候就涉及到Maven中依赖传递对版本的选择问题。依赖传递在选择版本的时候首先是根据深度选择的。当一个项目同时经过不同的路径依赖于同一个组件时,会选择其深度最短的对应组件进行依赖。举例来说,假设A->B->C->D1.0,A->E->D2.0,那么这个时候A就会选择对D相对路径短的组件来进行依赖,也就是D2.0。那么当深度一样的时候Maven会如何选择呢?即A->B->D1.0和A->C->D2.0,这个时候Maven会如何选择A所依赖的D的版本呢?这种情况Maven会根据申明的依赖顺序来进行选择,先申明的会被作为依赖包。向前面这种情况,如果先申明对B的依赖,则A依赖的就是D1.0,如果先申明对C的依赖,则A依赖的就是D2.0。

使用exclusion排除依赖

假设有这样一种依赖关系,A->B->C,这个时候由于某些原因,我们不需要对C的依赖,但是我们又必须要对B的依赖,这个时候该怎么办呢?针对这种情况,Maven给我们提供了一个exclusion功能,我们可以在添加A对B的依赖时申明不需要引进B对C的依赖。具体做法如下:

Xml代码  
  1. <dependencies>  
  2.        <dependency>  
  3.               <groupId>groupB</groupId>  
  4.               <artifactId>artifactB</artifactId>  
  5.               <version>1.0</version>  
  6.               <exclusions>  
  7.                      <exclusion>  
  8.                             <groupId>groupC</groupId>  
  9.                             <artifactId>artifactC</artifactId>  
  10.                      </exclusion>  
  11.               </exclusions>  
  12.        </dependency>  
  13.        ...  
  14. </dependencies>  

可选的依赖项

可选的依赖项表示可有可无,不一定需要的,它只是做一个标记。为了便于大家理解,我们先看这样一种情况,假设项目B依赖于项目C,这个时候我们把B对C的依赖利用optional标记为可选的,它意味着B中只有部分地方用到了C,并不是必须要的,当你依赖于B,但是又不需要使用到B的C功能时,可以不依赖于C。这样当A->B->C时,在建立项目A的时候将不会加入对C的依赖,因为C对B是可选的,我们不一定会用到C。但是在建立项目B的时候,Maven就会加入对C的依赖。也就是说这种标记为optional的依赖项对项目本身而言是没有什么影响的,它影响的是以该项目作为依赖项的其他项目,如这里的项目A。这种可选的依赖项有一个好处就是它会默认的作为exclusion项排除。

Xml代码  
  1. <project>  
  2.        <groupId>groupB</groupId>  
  3.        <artifactId>artifactB</artifactId>  
  4.        <version>1.0</version>  
  5.        <dependencies>  
  6.               <dependency>  
  7.                      <groupId>groupC</groupId>  
  8.                      <artifactId>artifactC</artifactId>  
  9.                      <version>1.0</version>  
  10.                      <optional>true</optional>  
  11.               </dependency>  
  12.               ...  
  13.        </dependencies>  
  14. </project>  
Xml代码  
  1.    
  2. <project>  
  3.        <groupId>groupA</groupId>  
  4.        <artifactId>artifactA</artifactId>  
  5.        <version>1.0</version>  
  6.        <dependencies>  
  7.               <dependency>  
  8.                      <groupId>groupB</groupId>  
  9.                      <artifactId>artifactB</artifactId>  
  10.                      <version>1.0</version>  
  11.               </dependency>  
  12.               ...  
  13.        </dependencies>  
  14. </project>  

7.2     依赖项的作用域

在定义项目的依赖项的时候,我们可以通过scope来指定该依赖项的作用范围。scope的取值有compile、runtime、test、provided、system和import。

compile:这是依赖项的默认作用范围,即当没有指定依赖项的scope时默认使用compile。compile范围内的依赖项在所有情况下都是有效的,包括运行、测试和编译时。

runtime:表示该依赖项只有在运行时才是需要的,在编译的时候不需要。这种类型的依赖项将在运行和test的类路径下可以访问。

test:表示该依赖项只对测试时有用,包括测试代码的编译和运行,对于正常的项目运行是没有影响的。

provided:表示该依赖项将由JDK或者运行容器在运行时提供,也就是说由Maven提供的该依赖项我们只有在编译和测试时才会用到,而在运行时将由JDK或者运行容器提供。

system:当scope为system时,表示该依赖项是我们自己提供的,不需要Maven到仓库里面去找。指定scope为system需要与另一个属性元素systemPath一起使用,它表示该依赖项在当前系统的位置,使用的是绝对路径。比如官网给出了一个关于使用JDK的tools.jar的例子:

Xml代码  
  1. <project>  
  2.   ...  
  3.   <dependencies>  
  4.     <dependency>  
  5.       <groupId>sun.jdk</groupId>  
  6.       <artifactId>tools</artifactId>  
  7.       <version>1.5.0</version>  
  8.       <scope>system</scope>  
  9.       <systemPath>${java.home}/../lib/tools.jar</systemPath>  
  10.     </dependency>  
  11.   </dependencies>  
  12.   ...  
  13. </project>  

import:关于import的介绍,可以看后文中对引入依赖项的介绍。

原文地址:https://www.cnblogs.com/yaowen/p/8609095.html