Maven（二）：Maven概念模型及坐标与依赖

Maven概念模型

Maven作为项目管理工具软件，可以通过一小段描述信息来管理项目的构建，安装并生成报告和文档。其中主要核心可以分为三步：
（1）根据项目pom.xml文件所描述的信息转换为POM (项目对象模型 Project Object Model)，并通过坐标与依赖关系找出该项目所依赖的包，这块也是本章介绍的内容
（2）去本地或远远程仓库中找到项目依赖的包引入项目中（这一块将在后面的仓库与配置中讲解）
（3）根据mvn命令所对应生命周期来执行相应的插件，获得对应的输出 （这一块将在后面的生命周期和插件中讲解）
下面从坐标和依赖两块来看pom.xml中常见标签

坐标

为了能自动化地解析任何一个Java构件, Maven必须将它们唯一标识, 这就是依赖管理的底层基础-坐标.
任何一个构件都必须明确定义自己的坐标, 坐标元素包括groupId、artifactId、version、packaging、classfier

<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus-indexer</artifactId>
<version>2.0.0</version>

• groupId：定义当前模块隶属的实际Maven项目
• artifactId：定义实际项目中的一个Maven模块
• version：定义当前项目所处版本
• packaging：定义Maven项目打包方式, 有war、pom、maven-plugin等,默认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是可选的，classifier是不能直接定义的，必须有插件的帮助才能生成。
项目的文件名是与坐标相对应的，一般为：artifactId-version[-classfier]. packaging,本地仓库中项目所在位置也与坐标相对应，一般为：本地仓库地址/groupId/ artifactId/ version/ artifactId-version[-classfier]. Packaging

依赖

Maven的依赖管理,使我们不必再到开源项目的官网一个个下载开源组件, 然后再一个个放入classpath. 一个依赖声明可以包含如下元素:

<dependencies>
<dependency>
    <groupId>…</groupId>
    <artifactId>…</artifactId>
    <version>…</version>
    <type>…</type>
    <scope>…</scope>
    <optional>….</optional>
    <exclusions>
        <exclusion>
            <groupId>…</groupId>
			<artifactId>…</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependencies>

dependencies可以包含一个或多个dependency元素，以声明一个或多个项目依赖，下面来看下这些元素：

groupId、artifactId、version

依赖的基本坐标，Maven根据坐标才能找到需要的依赖。

type

依赖的类型, 对应于项目坐标定义的packaging，默认jar

scope

依赖范围

一．依赖范围

依赖范围就是用来控制依赖与三种classpath（编译classpath、测试classpath、运行classpath）的关系，Maven有以下几种依赖范围：

• compile: 默认编译依赖范围。对于编译，测试，运行三种classpath都有效。
• test: 测试依赖范围。只对于测试classpath有效，只对测试代码有效。
• provided:
  已提供依赖范围。对于编译，测试的classpath都有效，但对于运行无效。因为由容器已经提供，例如servlet-api，打包的时候这个包不会打进去。
• runtime:运行时依赖范围。对于测试，运行classpath有效。例如jdbc驱动。

Compile、runtime打包会打进去，test、provided打包不会打进去
此外还有两种：

• system:系统依赖范围。依赖范围与pprovided一致，由于此类依赖往往与本机系统绑定，可能造成构建的不可移植，应谨慎使用。
• import:导入依赖范围，不会对三种classpath产生影响。

二．传递性依赖

依赖范围不仅可以控制依赖与三种classpath的关系，还对传递性依赖产生影响。假设A依赖于B，B依赖于C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖，那么第一直接依赖范围和第二指节依赖反为决定了传递性依赖范围。如下表素食，最左边一列是的第一直接依赖范围，最上面一行是第二指节额依赖范围，中间交叉的单元格则表示传递性依赖范围

	compile	test	provided	runtime
compile	compile	-	-	runtime
test	test	-	-	test
provided	provided	-	provided	provided
runtime	runtime	-	-	runtime

三．依赖冲突

如果项目A有这样的依赖关系：A->B->C->X(1.0),A->D->X(2.0),X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被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）依赖路径长度一样时又该解析哪个呢？
第二原则：第一声明者优先
在依赖路径长度相等的前提下，在POM中依顺序决定谁会被解析使用

optional

标记依赖是否可选。可能项目中实现了两个特性，并且这两种特性是互斥的，用户不能同时使用这两种特性。比如一个Jar包支持MySQL与Oracle两种DB, 因此其构建时必须添加两类驱动, 但用户使用时只会选择一种DB。 元素表示依赖为可选依赖，只会对当前项目产生影响，当其他项目依赖于当前项目时，optional标记的依赖不会被传递。

exclusion

用来排除传递性依。exclusions可以包含一个或多个exclusion子元素，因此可以排除一个或多个传递性依赖。

参考：《Maven实战》