一:依赖配置   

  我们在实际开发汇中最常见的maven依赖如下,读者可以看到最基本的groupId,artifactId,version等元素组成。



1 <dependency>
 2    <groupId>...</groupId>
 3    <artifactId>...</artifactId>
 4    <version>..</version>
 5    <type>...</type>
 6    <scope>...<scope>
 7    <optional>...<optional>
 8    <exclusions> 
 9     <exclusion>
10       </exclusion>
11    </exclusions>
12 <dependency>



   1.groupId、artifactId和version:依赖的基本坐标,对于任何一个依赖来说,基本坐标最重要,Maven根据坐标才能找到需要的依赖。

   2.type依赖类型,对于项目坐标定义的packaging。大部分情况下,该元素不必要声明,其默认值为jar。

   3.scope 依赖范围。我们会在后面详细介绍。

   4.optional:标记依赖是否可选。

   5.exclusions:用来排除传递性依赖。

在实际应用中只包含最基本的坐标,然而在一些特殊情况下,其他元素至关重要。

  二.依赖范围

   依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系,Maven有以下几种依赖范围。

   1.compile: 编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的maven依赖,对于编译 测试 运行三种的classpath都有效。

   2.test:测试依赖范围。使用此依赖范围的Maven依赖,只对于测试的classpath有效,在编译主代码或者运行主代码的时候都无法依赖此类依赖。典型的例子是jUnit,它只有在编译测试代码及运行测试代码的时候才有效。

   3.provided:以提供依赖范围。使用此依赖范围的maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行的时候,由于容器已经提供,就不需要maven重复地引入一遍。打包的时候可以不用包进去,别的设施会提供。事实上该依赖理论上可以参与编译,测试,运行等周期。相当于compile,但是打包阶段做了exclude操作

  4.runtime:运行时依赖范围。使用此依赖范围的maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要jdk提供的jdbc的接口,只有在执行测试或者运行测试的时候才需要实现上述接口的jdbc的驱动

 5.system:系统依赖范围。从参与度来说,和provided相同,不过被依赖项不会从maven仓库下载,而是从本地文件系统拿。需要添加systemPath的属性来定义路径,该依赖与三种范围的classpath

和provided依赖范围完全一致。可能造成不可移植,谨慎使用。

 6.import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。只有在dependencyManagement下才有效果。

 

3.传递性依赖

A依赖B,B依赖C。当前项目为A,只当B在A项目中的scope,那么c在A中的scope是如何得知呢?

当C是test或者provided时,C直接被丢弃,A不依赖C;(排除传递依赖)

否则A依赖C,C的scope继承与B的scope。maven会解析各个依赖的pom,将那些必要的间接依赖,一传递性依赖的形式引入到当前的项目中。

 3.传递性依赖范围

假设A依赖于B,B依赖于C,我们说A对于B是第一直接依赖,B对于C第二直接依赖,A对于C的传递性依赖。

 

4.依赖调解

 针对于传递性依赖造成问题的时候,我们需要清楚知道传递性依赖的从哪条路径引入的。例如A->B-C->X(1.0)  A->D

->X(2.0),两条路径有两个版本的X,两个版本都被解析是不对的,因为会造成依赖重复,因此必须选择一个。maven依赖调解(Dependency Mediation)第一条原则是:路径最近者优先。因此X(2.0)会被解析使用。当路径相同时我们采取第二条准则,第一声明者优先。即谁在pom文件中先声明,先被解析。

5.排除依赖
 exclusions 可以包含一个多个exclusion元素,可以排除一个或多个项目。