Maven 教程
1、Maven概述
Maven 是什么？
Maven 是一个项目管理和整合工具。Maven 为开发者提供了一套完整的构建生命周期框架。开发团队几乎不用花多少时间就能够自动完成工程的基础构建配置，因为 Maven 使用了一个标准的目录结构和一个默认的构建生命周期。
在有多个开发团队环境的情况下，Maven 能够在很短的时间内使得每项工作都按照标准进行。因为大部分的工程配置操作都非常简单并且可复用，在创建报告、检查、构建和测试自动配置时，Maven 可以让开发者的工作变得更简单。
Maven 能够帮助开发者完成以下工作：
- 构建
- 文档生成
- 报告
- 依赖
- SCMs
- 发布
- 分发
- 邮件列表
总的来说，Maven 简化了工程的构建过程，并对其标准化。它无缝衔接了编译、发布、文档生成、团队合作和其他任务。Maven 提高了重用性，负责了大部分构建相关的任务。
Maven 的历史
Maven 最初是在 Jakarta Turbine 项目中为了简化构建过程而设计的。项目中有几个子工程，每个工程包含稍有不同的 ANT 文件。JAR 文件使用 CVS 管理。
Apache 小组随后开发了 Maven，能够同时构建多个工程、发布工程信息、部署工程、在几个工程中共享 JAR 文件，并且协助团队合作。
Maven 的目标
Maven 的主要目的是为开发者提供
- 一个可复用、可维护、更易理解的工程综合模型
- 与这个模型交互的插件或者工具
Maven 工程结构和内容被定义在一个 xml 文件中 － pom.xml，是 Project Object Model (POM) 的简称，此文件是整个 Maven 系统的基础组件。
约定优于配置
Maven 使用约定而不是配置，意味着开发者不需要再自己创建构建过程。
开发者不需要再关心每一个配置细节。Maven 为工程提供了合理的默认行为。当创建 Maven 工程时，Maven 会创建默认的工程结构。开发者只需要合理的放置文件，而在 pom.xml 中不再需要定义任何配置。
举例说明，下面的表格展示了工程源码文件、资源文件的默认配置，和其他一些配置。假定 ${basedir} 表示工程目录：
|
配置项 |
默认值 |
|
source code |
${basedir}/src/main/java |
|
resources |
${basedir}/src/main/resources |
|
Tests |
${basedir}/src/test |
|
Complied byte code |
${basedir}/target |
|
distributable JAR |
${basedir}/target/classes |
为了构建工程，Maven 为开发者提供了选项来配置生命周期目标和工程依赖（依赖于 Maven 的插件扩展功能和默认的约定）。大部分的工程管理和构建相关的任务是由 Maven 插件完成的。
开发人员不需要了解每个插件是如何工作的，就能够构建任何给定的 Maven 工程。详细内容请参考 Maven 插件部分。
2、Maven 环境配置
3、Maven POM文件
POM（project object model） 代表工程对象模型。它是使用 Maven 工作时的基本组建，是一个 xml 文件。它被放在工程根目录下，文件命名为 pom.xml。
POM 包含了关于工程和各种配置细节的信息，Maven 使用这些信息构建工程。
POM 也包含了目标和插件。当执行一个任务或者目标时，Maven 会查找当前目录下的 POM，从其中读取所需要的配置信息，然后执行目标。能够在 POM 中设置的一些配置如下：
- project dependencies
- plugins
- goals
- build profiles
- project version
- developers
- mailing list
在创建 POM 之前，我们首先确定工程组（groupId），及其名称（artifactId）和版本，在仓库中这些属性是工程的唯一标识。
POM 举例
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.companyname.project-group</groupId>
<artifactId>project</artifactId>
<version>1.0</version>
</project>
需要说明的是每个工程应该只有一个 POM 文件。
- 所有的 POM 文件需要 project 元素和三个必须的字段groupId,artifactId,version。
- 在仓库中的工程标识为 groupId:artifactId:version
- POM.xml 的根元素是 project，它有三个主要的子节点：
|
节点 |
描述 |
|
groupId |
这是工程组的标识。它在一个组织或者项目中通常是唯一的。例如，一个银行组织 com.company.bank 拥有所有的和银行相关的项目。 |
|
artifactId |
这是工程的标识。它通常是工程的名称。例如，消费者银行。groupId 和 artifactId 一起定义了 artifact 在仓库中的位置。 |
|
version |
这是工程的版本号。在 artifact 的仓库中，它用来区分不同的版本。例如： |
Super POM
所有的 POM 都继承自一个父 POM（无论是否显式定义了这个父 POM）。父 POM 也被称作 Super POM，它包含了一些可以被继承的默认设置。
Maven 使用 effective pom（Super pom 加上工程自己的配置）来执行相关的目标，它帮助开发者在 pom.xml 中做尽可能少的配置，当然这些配置可以被方便的重写。
查看 Super POM 默认配置的一个简单方法是执行以下命令：mvn help:effective-pom
在你的电脑上的任意目录下创建一个 pom.xml 文件，使用上面提到的示例 pom 中的内容。
POM详细配置
4、Maven 构建生命周期
什么是构建生命周期
构建生命周期是一组阶段的序列（sequence of phases），每个阶段定义了目标被执行的顺序。这里的阶段是生命周期的一部分。
举例说明，一个典型的 Maven 构建生命周期是由以下几个阶段的序列组成的：
|
阶段 |
处理 |
描述 |
|
prepare-resources |
资源拷贝 |
本阶段可以自定义需要拷贝的资源 |
|
compile |
编译 |
本阶段完成源代码编译 |
|
package |
打包 |
本阶段根据 pom.xml 中描述的打包配置创建 JAR / WAR 包 |
|
install |
安装 |
本阶段在本地 / 远程仓库中安装工程包 |
当需要在某个特定阶段之前或之后执行目标时，可以使用 pre 和 post 来定义这个目标。
当 Maven 开始构建工程，会按照所定义的阶段序列的顺序执行每个阶段注册的目标。
Maven 有以下三个标准的生命周期：
- clean
- default(or build)
- site
目标表示一个特定的、对构建和管理工程有帮助的任务。它可能绑定了 0 个或多个构建阶段。没有绑定任何构建阶段的目标可以在构建生命周期之外被直接调用执行。
执行的顺序依赖于目标和构建阶段被调用的顺序。例如，考虑下面的命令。clean 和 package 参数是构建阶段，而 dependency:copy-dependencies 是一个目标。
mvn clean dependency:copy-dependencies package这里的 clean 阶段将会被首先执行，然后 dependency:copy-dependencies 目标会被执行，最终 package 阶段被执行。
Clean 生命周期
当我们执行 mvn post-clean 命令时，Maven 调用 clean 生命周期，它包含以下阶段。
- pre-clean
- clean
- post-clean
Maven 的 clean 目标（clean:clean）绑定到了 clean 生命周期的 clean 阶段。它的 clean:clean 目标通过删除构建目录删除了构建输出。所以当 mvn clean 命令执行时，Maven 删除了构建目录。
我们可以通过在上面的 clean 生命周期的任何阶段定义目标来修改这部分的操作行为。
在下面的例子中，我们将 maven-antrun-plugin:run 目标添加到 pre-clean、clean 和 post-clean 阶段中。这样我们可以在 clean 生命周期的各个阶段显示文本信息。
示例：创建了一个 pom.xml 文件。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>id.pre-clean</id>
<phase>pre-clean</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>pre-clean phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.clean</id>
<phase>clean</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>clean phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.post-clean</id>
<phase>post-clean</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>post-clean phase</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
现在打开命令控制台，跳转到 pom.xml 所在目录，并执行下面的 mvn 命令。
C:MVNproject>mvn post-cleanMaven 将会开始处理并显示 clean 生命周期的所有阶段。
修改 mvn clean 命令，来显示 pre-clean 和 clean，而在 post-clean 阶段不执行任何操作。
Default (or Build) 生命周期
这是 Maven 的主要生命周期，被用于构建应用。包括下面的 23 个阶段。
|
生命周期阶段 |
描述 |
|
validate |
检查工程配置是否正确，完成构建过程的所有必要信息是否能够获取到。 |
|
initialize |
初始化构建状态，例如设置属性。 |
|
generate-sources |
生成编译阶段需要包含的任何源码文件。 |
|
process-sources |
处理源代码，例如，过滤任何值（filter any value）。 |
|
generate-resources |
生成工程包中需要包含的资源文件。 |
|
process-resources |
拷贝和处理资源文件到目的目录中，为打包阶段做准备。 |
|
compile |
编译工程源码。 |
|
process-classes |
处理编译生成的文件，例如 Java Class 字节码的加强和优化。 |
|
generate-test-sources |
生成编译阶段需要包含的任何测试源代码。 |
|
process-test-sources |
处理测试源代码，例如，过滤任何值（filter any values)。 |
|
test-compile |
编译测试源代码到测试目的目录。 |
|
process-test-classes |
处理测试代码文件编译后生成的文件。 |
|
test |
使用适当的单元测试框架（例如JUnit）运行测试。 |
|
prepare-package |
在真正打包之前，为准备打包执行任何必要的操作。 |
|
package |
获取编译后的代码，并按照可发布的格式进行打包，例如 JAR、WAR。 |
|
pre-integration-test |
在集成测试执行之前，执行所需的操作。例如，设置所需的环境变量。 |
|
integration-test |
处理和部署必须的工程包到集成测试能够运行的环境中。 |
|
post-integration-test |
在集成测试被执行后执行必要的操作。例如，清理环境。 |
|
verify |
运行检查操作来验证工程包是有效的，并满足质量要求。 |
|
install |
安装工程包到本地仓库中，该仓库可以作为本地其他工程的依赖。 |
|
deploy |
拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程。 |
有一些与 Maven 生命周期相关的重要概念需要说明：
当一个阶段通过 Maven 命令调用时，例如 mvn compile，只有该阶段之前以及包括该阶段在内的所有阶段会被执行。
不同的 maven 目标将根据打包的类型（JAR / WAR / EAR），被绑定到不同的 Maven 生命周期阶段。
在下面的例子中，我们将 maven-antrun-plugin:run 目标添加到 Build 生命周期的一部分阶段中。这样我们可以显示生命周期的文本信息。
我们已经更新了 C:MVNproject 目录下的 pom.xml 文件。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>id.validate</id>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>validate phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.compile</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>compile phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.test</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>test phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.package</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>package phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.deploy</id>
<phase>deploy</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>deploy phase</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
现在打开命令控制台，跳转到 pom.xml 所在目录，并执行以下 mvn 命令。
C:MVNproject>mvn compileSite 生命周期
Maven Site 插件一般用来创建新的报告文档、部署站点等。
阶段：
- pre-site
- site
- post-site
- site-deploy
在下面的例子中，我们将 maven-antrun-plugin:run 目标添加到 Site 生命周期的所有阶段中。这样我们可以显示生命周期的所有文本信息。
更新pom.xml 文件。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>id.pre-site</id>
<phase>pre-site</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>pre-site phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.site</id>
<phase>site</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>site phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.post-site</id>
<phase>post-site</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>post-site phase</echo>
</tasks>
</configuration>
</execution>
<execution>
<id>id.site-deploy</id>
<phase>site-deploy</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>site-deploy phase</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
现在打开命令控制台，跳转到 pom.xml 所在目录，并执行以下 mvn 命令。
C:MVNproject>mvn siteMaven 将会开始处理并显示直到 site 阶段的 site 生命周期的各个阶段。
5、Maven 构建配置文件profile
Profile简介
profile可以让我们定义一系列的配置信息，然后指定其激活条件。这样我们就可以定义多个profile，然后每个profile对应不同的激活条件和配置信息，从而达到不同环境使用不同配置信息的效果。比如说，我们可以通过profile定义在jdk1.5以上使用一套配置信息，在jdk1.5以下使用另外一套配置信息；或者有时候我们可以通过操作系统的不同来使用不同的配置信息，比如windows下是一套信息，Linux下又是另外一套信息，等等。
Profile位置定义
（1）针对于特定项目的profile配置我们可以定义在该项目的pom.xml中。
（2）针对于特定用户的profile配置，我们可以在用户的settings.xml文件中定义profile。该文件在用户家目录下的“.m2”目录下。
（3）全局的profile配置。全局的profile是定义在Maven安装目录下的“conf/settings.xml”文件中的。
Profile的激活方式
(1) 使用activeByDefault设置默认激活
例如：
<profile>
<id>testProfileByDefault</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
(2) 在settings.xml中使用activeProfiles指定处于激活状态的profile
<profiles>
<profile>
<id>profileTest1</id>
<properties>
<hello>world</hello>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>profileTest1</activeProfile>
</activeProfiles>
(3) 使用-P参数显示的激活一个profile
使用mvn package –P profileTest1 命令激活
(4)根据环境来激活
1> 根据jdk来激活profile
<profiles>
<profile>
<id>profileTest1</id>
<jdk>1.5</jdk>
</profile>
<profiles>
2> 根据操作系统来激活profile
<profiles>
<profile>
<id>profileTest1</id>
<activation>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
<version>5.1.2600</version>
</os>
</activation>
</profile>
</profiles>
3>根据系统属性来激活profile
<profiles>
<profile>
<id>profileTest1</id>
<activation>
<property>
<name>hello</name>
<value>world</value>
</property>
</activation>
</profile>
</profiles>
当系统提供属性为hello值为world的时候被激活，mvn package –Dhello=world
4>根据文件是否存在激活profile
<profiles>
<profile>
<id>profileTest1</id>
<activation>
<file>
<exists>target</exists>
<!-- <missing>target</missing> -->
</file>
</activation>
</profile>
</profiles>
上面的定义表示当存在target文件时激活profileTest1。
查看当前处于激活状态的profile
使用mvn help:active-profiles查看处于激活状态的profile
6、Maven 仓库
什么是 Maven 仓库？
在 Maven 的术语中，仓库是一个位置（place），例如目录，可以存储所有的工程 jar 文件、library jar 文件、插件或任何其他的工程指定的文件。
Maven 仓库有三种类型：
- 本地（local）
- 中央（central）
- 远程（remote）
本地仓库
Maven 本地仓库是机器上的一个文件夹。它在你第一次运行任何 maven 命令的时候创建。
Maven 本地仓库保存你的工程的所有依赖（library jar、plugin jar 等）。当你运行一次 Maven 构建，Maven 会自动下载所有依赖的 jar 文件到本地仓库中。它避免了每次构建时都引用存放在远程机器上的依赖文件。
Maven 本地仓库默认被创建在 %USER_HOME% 目录下。要修改默认位置，在 %M2_HOME%conf 目录中的 Maven 的 settings.xml 文件中定义另一个路径。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>C:/MyLocalRepository</localRepository>
</settings>
当你运行 Maven 命令，Maven 将下载依赖的文件到你指定的路径中。
中央仓库
Maven 中央仓库是由 Maven 社区提供的仓库，其中包含了大量常用的库。
中央仓库的关键概念：
- 这个仓库由 Maven 社区管理。
- 不需要配置。
- 需要通过网络才能访问。
要浏览中央仓库的内容，maven 社区提供了一个 URL：http://search.maven.org/#browse。使用这个仓库，开发人员可以搜索所有可以获取的代码库。
远程仓库
如果 Maven 在中央仓库中也找不到依赖的库文件，它会停止构建过程并输出错误信息到控制台。为避免这种情况，Maven 提供了远程仓库的概念，它是开发人员自己定制仓库，包含了所需要的代码库或者其他工程中用到的 jar 文件。
举例说明，使用下面的 POM.xml，Maven 将从远程仓库中下载该 pom.xml 中声明的所依赖的（在中央仓库中获取不到的）文件。
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.companyname.projectgroup</groupId>
<artifactId>project</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>com.companyname.common-lib</groupId>
<artifactId>common-lib</artifactId>
<version>1.0.0</version>
</dependency>
<dependencies>
<repositories>
<repository>
<id>companyname.lib1</id>
<url>http://download.companyname.org/maven2/lib1</url>
</repository>
<repository>
<id>companyname.lib2</id>
<url>http://download.companyname.org/maven2/lib2</url>
</repository>
</repositories>
</project>
Maven 依赖搜索顺序
当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：
- 步骤 1 － 在本地仓库中搜索，如果找不到，执行步骤 2，如果找到了则执行其他操作。
- 步骤 2 － 在中央仓库中搜索，如果找不到，并且有一个或多个远程仓库已经设置，则执行步骤 4，如果找到了则下载到本地仓库中已被将来引用。
- 步骤 3 － 如果远程仓库没有被设置，Maven 将简单的停滞处理并抛出错误（无法找到依赖的文件）。
- 步骤 4 － 在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库已被将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。
Maven 仓库优先级
在maven中主要有以下几种仓库的设置，本地仓库，settings里面profile中设置的仓库，mirror仓库，pom文件中的repository。
优先级：本地仓库 >profile > pom中的repository > mirror
注意：
mirror这样设置：
<mirror>
<id>huacloud-central</id>
<mirrorOf>*</mirrorOf>
<name>name-of-this</name>
<url>http://222.197.XXXXXX/nexus/content/groups/public/</url>
</mirror>
表示该仓库地址为所有仓库的镜像，那么这个时候，maven会忽略掉其他设置的各种类型仓库仓库，只在mirror里面找。
7、Maven 插件
什么是 Maven 插件？
Maven 实际上是一个依赖插件执行的框架，每个任务实际上是由插件完成。Maven 插件通常被用来：
- 创建 jar 文件
- 创建 war 文件
- 编译代码文件
- 代码单元测试
- 创建工程文档
- 创建工程报告
插件通常提供了一个目标的集合，并且可以使用下面的语法执行：
mvn[plugin-name]:[goal-name]
例如，一个 Java 工程可以使用 maven-compiler-plugin 的 compile-goal 编译，使用以下命令：
mvn compiler:compile
插件类型
Maven 提供了下面两种类型的插件：
|
类型 |
描述 |
|
Build plugins |
在构建时执行，并在 pom.xml 的 元素中配置。 |
|
Reporting plugins |
在网站生成过程中执行，并在 pom.xml 的 元素中配置。 |
下面是一些常用插件的列表：
|
插件 |
描述 |
|
clean |
构建之后清理目标文件。删除目标目录。 |
|
compiler |
编译 Java 源文件。 |
|
surefile |
运行 JUnit 单元测试。创建测试报告。 |
|
jar |
从当前工程中构建 JAR 文件。 |
|
war |
从当前工程中构建 WAR 文件。 |
|
javadoc |
为工程生成 Javadoc。 |
|
antrun |
从构建过程的任意一个阶段中运行一个 ant 任务的集合。 |
8、Maven 外部依赖
出现场景
现在，如你所知道的，Maven的依赖管理使用的是 Maven - 仓库 的概念。但是如果在远程仓库和中央仓库中，依赖不能被满足，如何解决呢? Maven 使用外部依赖的概念来解决这个问题。
例如，让我们对在 Maven - 创建工程 部分创建的项目做以下修改：
- 在 src 文件夹下添加 lib 文件夹
- 复制任何 jar 文件到 lib 文件夹下。我们使用的是 ldapjdk.jar ，它是为 LDAP 操作的一个帮助库
现在，我们的工程结构应该像下图一样：
现在你有了自己的工程库（library），通常情况下它会包含一些任何仓库无法使用，并且 maven 也无法下载的 jar 文件。如果你的代码正在使用这个库，那么 Maven 的构建过程将会失败，因为在编译阶段它不能下载或者引用这个库。
为了处理这种情况，让我们用以下方式。
引用方式
方式一：编译阶段指定外部lib。
<dependencies>
<dependency>
<groupId>ldapjdk</groupId>
<artifactId>ldapjdk</artifactId>
<scope>system</scope>
<version>1.0</version>
<systemPath>${basedir}/src/lib/ldapjdk.jar</systemPath>
</dependency>
</dependencies>
上例中， <dependencies> 的第二个 <dependency> 元素 , 阐明了外部依赖的关键概念。
- 外部依赖（library jar location）能够像其他依赖一样在 pom.xml 中配置。
- 指定 groupId 为 library 的名称。
- 指定 artifactId 为 library 的名称。
- 指定作用域（scope）为系统。
- 指定相对于工程位置的系统路径。
方式二：将外部jar打入本地maven仓库
运行命令：mvn install:install-file -Dfile=ldapjdk.jar -DgroupId=com.local.ldapjdk -DartifactId= ldapjdk -Dversion=1.0 -Dpackaging=jar
引入依赖:
方式三： 编译阶段指定外部lib
<dependency>
<groupId>com.local.ldapjdk</groupId>
<artifactId>ldapjdk </artifactId>
<version>1.0</version>
</dependency>
8、Maven 管理依赖
Maven 核心特点之一是依赖管理。一旦我们开始处理多模块工程（包含数百个子模块或者子工程）的时候，模块间的依赖关系就变得非常复杂，管理也变得很困难。针对此种情形，Maven 提供了一种高度控制的方法。
传递依赖发现
这种情形经常可见，当一个库 A 依赖于其他库 B. 另一工程 C 想要使用库 A, 那么该工程同样也需要使用到库 B。
Maven 可以避免去搜索所有需要的库资源的这种需求。通过读取工程文件（pom.xml）中的依赖项，Maven 可以找出工程之间的依赖关系。
我们只需要在每个工程的 pom 文件里去定义直接的依赖关系。Maven 则会自动的来接管后续的工作。
通过传递依赖，所有被包含的库的图形可能会快速的增长。当重复的库存在时，可能出现的情形将会持续上升。Maven 提供一些功能来控制可传递的依赖的程度。
|
功能 |
功能描述 |
|
依赖调节 |
决定当多个手动创建的版本同时出现时，哪个依赖版本将会被使用。 如果两个依赖版本在依赖树里的深度是一样的时候，第一个被声明的依赖将会被使用。 |
|
依赖管理 |
直接的指定手动创建的某个版本被使用。例如当一个工程 C 在自己的以来管理模块包含工程 B，即 B 依赖于 A， 那么 A 即可指定在 B 被引用时所使用的版本。 |
|
依赖范围 |
包含在构建过程每个阶段的依赖。 |
|
依赖排除 |
任何可传递的依赖都可以通过 "exclusion" 元素被排除在外。举例说明，A 依赖 B， B 依赖 C，因此 A 可以标记 C 为 “被排除的”。 |
|
依赖可选 |
任何可传递的依赖可以被标记为可选的，通过使用 "optional" 元素。例如：A 依赖 B， B 依赖 C。因此，B 可以标记 C 为可选的， 这样 A 就可以不再使用 C。 |
依赖范围
传递依赖发现可以通过使用如下的依赖范围来得到限制：
|
范围 |
描述 |
|
编译阶段 |
该范围表明相关依赖是只在工程的类路径下有效。默认取值。 |
|
供应阶段 |
该范围表明相关依赖是由运行时的 JDK 或者 网络服务器提供的。 |
|
运行阶段 |
该范围表明相关依赖在编译阶段不是必须的，但是在执行阶段是必须的。 |
|
测试阶段 |
该范围表明相关依赖只在测试编译阶段和执行阶段。 |
|
系统阶段 |
该范围表明你需要提供一个系统路径。 |
|
导入阶段 |
该范围只在依赖是一个 pom 里定义的依赖时使用。同时，当前工程的POM 文件的 部分定义的依赖关系可以取代某特定的 POM。 |