Maven之pom.xml依赖的配置

1.坐标详解
Maven坐标为各种构件引入了秩序,任何一个构件都必须明确定义自己的坐标,而一组Maven坐标是通过一些元素定义的,它们是groupId、artifactId、version、packaging、classifier。
groupId： 定义当前Maven项目隶属的实际项目。
artifactId： 该元素定义实际项目中的一个Maven项目（模块）,推荐的做法是使用实际项目名称作为artifactId的前缀。
version： 该元素定义Maven项目当前所处的版本
packaging： 该元素定义Maven项目的打包方式,当不定义packaging的时候,Maven会使用默认值jar。
classifier： 该元素用来帮助定义构建输出的一些附属构件。附属构件与主构件对应,如上例中的主构件是nexus-indexer-2.0.0.jar,该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些附属构件,其包含了Java文档和源代码。这时候,javadoc和sources就是这两个附属构件的classifier。这样,附属构件也就拥有了自己唯一的坐标。
上述5个元素中,groupId、artifactId、version是必须定义的,packaging是可选的（默认为jar）,而classifier是不能直接定义的。
同时,项目构件的文件名是与坐标相对应的,一般的规则为artifactId-version［-classifier］.packaging,［-classifier］表示可选。
这里还要强调的一点是,packaging并非一定与构件扩展名对应,比如packaging为maven-plugin的构件扩展名为jar。

2.依赖配置格式
根元素project下的dependencies可以包含一个或者多个dependency元素,以声明一个或者多个项目依赖。每个依赖可以包含的
元素有：
groupId、artifactId和version： 依赖的基本坐标,对于任何一个依赖来说,基本坐标是最重要的,Maven根据坐标才能找到需要的依赖。
type： 依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认值为jar。
scope： 依赖的范围,依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系,Maven有以下几种依赖范围：
compile： 编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。
test： 测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此类依赖。
provided： 已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要Maven重复地引入一遍。
runtime： 运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system： 系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使用。
import（Maven 2.0.9及以上）： 导入依赖范围。该依赖范围不会对三种classpath产生实际的影响,本书将在8.3.3节介绍Maven依赖和dependencyManagement的时候详细介绍此依赖范围。
大部分依赖声明只包含基本坐标,然而在一些特殊情况下,其他元素至关重要。

3.传递性依赖
有了传递性依赖机制,在使用Spring Framework的时候就不用去考虑它依赖了什么,也不用担心引入多余的依赖。Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目中。

4.传递性依赖和依赖范围
当第二直接依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致；当第二直接依赖的范围是test的时候,依赖不会得以传递；当第二直接依赖的范围是provided的时候,只传递第一直接依赖范围也为provided的依赖,且传递性依赖的范围同样为provided；当第二直接依赖的范围是runtime的时候,传递性依赖的范围与第一直接依赖的范围一致,但compile例外,此时传递性依赖的范围为runtime。

5.依赖调解
例如,项目A有这样的依赖关系：A->B->C->X（1.0）、A->D->X（2.0）,X是A的传递性依赖,但是两条依赖路径上有两个版本的X,那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的,因为那会造成依赖重复,因此必须选择一个。Maven依赖调解（Dependency Mediation）的第一原则是：路径最近者优先。该例中X（1.0）的路径长度为3,而X（2.0）的路径长度为2,因此X（2.0）会被解析使用。
Maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下,在POM中依赖声明的顺序决定了谁会被解析使用,顺序最靠前的那个依赖优胜。

6.可选依赖

true

元素表示可选依赖.
项目B实现了两个特性,其中的特性一依赖于X,特性二依赖于Y,而且这两个特性是互斥的,用户不可能同时使用两个特性。比如B是一个持久层隔离工具包,它支持多种数据库,包括MySQL、PostgreSQL等,在构建这个工具包的时候,需要这两种数据库的驱动程序,但在使用这个工具包的时候,只会依赖一种数据库。

7.排除依赖

....

项目A依赖于项目B,但是由于一些原因,不想引入传递性依赖C,而是自己显式地声明对于项目C 1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖,exclusions可以包含一个或者多个exclusion子元素,因此可以排除一个或者多个传递性依赖。需要注意的是,声明exclusion的时候只需要groupId和artifactId,而不需要version元素,这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说,Maven解析后的依赖中,不可能出现groupId和artifactId相同,但是version不同的两个依赖

8.归类依赖

....

<变量名>值





${变量名}

这里简单用到了Maven属性,首先使用properties元素定义Maven属性,使用美元符号和大括弧环绕的方式引用Maven属性。然后,将所有依赖的版本值用这一属性引用表示。这和在Java中用常量PI替换3.14是同样的道理,不同的只是语法。

9.优化依赖
运行命令查看当前项目的已解析依赖：mvn dependency:list,在此基础上,还能进一步了解已解析依赖的信息。将直接在当前项目POM声明的依赖定义为顶层依赖,而这些顶层依赖的依赖则定义为第二层依赖,以此类推,有第三、第四层依赖。当这些依赖经Maven解析后,就会构成一个依赖树,通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以行如下命令查看当前项目的依赖树：mvn dependency:tree,在此基础上,还有dependency：analyze工具可以帮助分析当前项目的依赖。为了说明该工具的用途,先将spring-context这一依赖删除,然后构建项目,你会发现编译、测试和打包都不会有任何问题。通过分析依赖树,可以看到spring-context是spring-context-support的依赖,因此会得以传递到项目的classspath中。