一. Maven生命周期
1.1 何为生命周期
我们在开发项目的时候，我们不断地在经历编译、测试、打包、部署等过程，maven的生命周期就是对所有这些过程的一个抽象与统一，她的生命周期包含项目的清理、初始化、编译、测试、打包、集成测试、验证、部署、站点生成等几乎所有的过程，而且maven的生命周期是及其灵活，它生命周期的每个阶段是通过插件来实现的，maven也内置了很多插件，所以我们在项目进行编译、测试、打包的过程是没有感觉到。像编译是通过maven-compile-plugin实现的、测试是通过maven-surefire-plugin实现的。
举例说明生命周期的概念：
1 public abstract class AbstractBuild { 2 public void build() { 3 initialize(); 4 compile(); 5 test(); 6 packagee(); 7 integrationTest(); 8 deploy(); 9 } 10 11 protected abstract void initialize(); 12 protected abstract void compile(); 13 protected abstract void test(); 14 protected abstract void packagee(); 15 protected abstract void integrationTest(); 16 protected abstract void deploy(); 17 18 }
说明：上面的build()方法定义了整个构建的过程，依次初始化、编译、测试、打包、集成测试和部署。build()方法就可以抽象成为生命周期的概念，它包含了很多阶段的执行次序等信息，比如test阶段，这些阶段只是定义，但是具体的实现是通过插件来实现的。
1.2 生命周期的分类
Maven拥有三套相互独立的生命周期，它们分别为clean、default和site。clean的生命周期的目的是清理项目，default生命周期的目的是构建项目，而site生命周期的目的是建立项目站点。它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site运行所有这三套生命周期。
每个生命周期包含一些阶段，这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段。以clean生命周期为例，它包含的阶段有pre-clean、clean和post-clean。当用户调用pre-clean的时候，只有pre-clean阶段得到执行；当用户调用clean的时候，pre-clean和clean阶段会得以顺序执行；当用户调用post-clean的时候，pre-clean、clean和post-clean会得以顺序执行。
1.2.1 clean生命周期
Clean生命周期一共包含了三个阶段：
- pre-clean 执行一些需要在clean之前完成的工作。
- clean 移除所有上一次构建生成的文件。
- post-clean 执行一些需要在clean之后立刻完成的工作。
mvn clean中的clean就是上面的clean，在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean等同于 mvn pre-clean clean，如果我们运行 mvn post-clean，那么 pre-clean、clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。
1.2.2 site生命周期
site生命周期的目的是建立和发布项目站点，Maven能够基于POM所包含的信息，自动的生成一个友好的站点，方便团队交流和发布项目信息。该生命周期包含阶段如下：
- pre-site:执行一些在生成项目站点之前需要完成的工作。
- site:生成项目站点文档。
- post-site:执行一些在生成项目站点之后需要完成的工作。
- site-deploy:将生成的项目站点发布到服务器上。
1.2.3 default生命周期
default生命周期定义了真正构建时所需要执行的所有步骤，它是所有生命周期中最核心的部分，其包含的阶段如下，这里只对重要的阶段进行解释：
- validate
- initialize
- generate-sources
- process-sources
- generate-resources: 处理项目主资源文件。一般来说，是对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中
- genetate-resources
- process-resources
- compile:编译项目的主代码。一般来说，是编译src/main/java目录下的java文件至项目输出的主classpath目录中。
- process-classes
- generate-test-sources
- process-test-sources:处理项目测试资源文件。一般来说，是对src/test/resources目录的内容进行变量替换工作后，复制到项目输出的测试classpath目录下。
- generate-test-resources
- process-test-resources
- test-compile:编译项目的测试代码。一般来说，是编译src/test/java目录下的java文件至项目输出的测试classpath目录中。
- process-test-classes
- test：使用单元测试框架运行测试，测试代码不会被打包或者部署。
- prepare-package
- package:接受编译好的代码，打包成可发布的格式，如JAR。
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install:将安装包安装到Maven仓库，供本地其他的Maven项目使用。
- deploy:将最终的包复制到远程仓库，供其他开发人员和Maven项目使用。
上面未标明的可以参阅官方的解释：http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html。
1.3 命令行与生命周期
从命令行执行Maven任务的最主要方式就是调用Maven的生命周期阶段。
二. 插件
2.1 插件目标
对于插件本身，为了能够复用代码，它往往能够完成多个任务。例如maven-dependency-plugin,它能基于项目依赖做很多的事情，它能够分析项目依赖，帮助找出潜在的无用的依赖，他能列出依赖数，帮助分析依赖来源，他能列出项目所有已解析的依赖等等，为每个这样的功能编写一个独立的插件显然是不可取的，因为这些任务背后有很多的可以复用的代码，因此这些功能聚集在一个插件里，每个功能就是一个插件目标。
举例，maven-denpendency-plugin有十多个目标，每个目标对应一个功能，上述提到的几个功能分别对应的插件目标为dependency：analyze、dependency:tree、dependency:list这是一种通用的写法，冒号前面是插件前缀，冒号后面是该插件的目标。类似的，还可以写出compiler:compile(这是maven-compiler-plugin的compile目标)和surefire：test（这是maven-sure-fire-plugin的test目标）。
2.2 插件绑定
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。例如项目编译这一任务，它对应了default生命周期的compile这一阶段，而maven-compiler-plugin这一插件的compile目标能够完成该任务。因此将它们绑定，就能实现项目编译的目的。
2.2.1 内置绑定
为了让用户不用做任何配置就能构建Maven项目，Maven在核心为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用声明周期阶段时，对应的插件目标就会执行相应的任务。生命周期阶段与插件目标对应表如下：
表一：clean生命周期阶段与插件目标的绑定关系
| 生命周期阶段 | 插件关系 |
|---|---|
| pre-clean | . |
| clean | maven-clean-plugin:clean |
| post-clean | . |
表二：default生命周期阶段与插件目标的绑定关系
| 生命周期阶段 | 插件目标 | 执行任务 |
|---|---|---|
| process-resources | maven-resources-plugin:resources | 复制主资源文件至主输出目录 |
| compile | maven-compiler-plugin:compile | 编译主代码至主输出目录 |
| process-test-resources | maven-resources-plugin:testResources | 复制测试资源文件至测试输出目录 |
| test-compile | maven-compiler-plugin:testCompile | 编译测试代码至测试输出目录 |
| test | maven-surefire-plugin:test | 执行测试用例 |
| package | maven-jar-plugin:jar | 创建项目jar包 |
| install | maven-install-plugin:install | 将项目输出构件安装到本地仓库 |
| deploy | maven-deploy-plugin:deploy | 将项目输出构件部署到远程仓库 |
上面default生命周期还有很多其他阶段，默认他们没有绑定任何插件，因此也没有任何实际行为。
表三：site生命周期阶段与插件目标的绑定关系
| 生命周期阶段 | 插件目标 |
|---|---|
| pre-site | . |
| site | maven-site-plugin：site |
| post-site | . |
| site-deploy | maven-site-plugin.deploy |
举例说明：
比如我们在项目下执行了mvn post-clean:
从绿色的插件部分就可以看到对应的插件目标，以及对应的生命周期阶段。
2.2.2 自定义绑定
暂时不管这个。
2.3 插件配置
完成插件和生命周期的绑定后，用户还可以配置插件目标的参数，进一步调整插件目标所执行的任务，以满足项目的需求。几乎所有的Maven插件的目标都有一些可配置的参数，用户可以通过命令行和POM配置的方式来配置这些参数。
2.3.1 命令行插件配置
用户可以在Maven命令中使用-D参数，并伴随一个参数键=参数值得形式，来配置插件目标的参数。
例如，maven-surefire-plugin提供了一个maven.test.skip参数，当其值为true的时候，就会跳过执行测试，于是在运行命令的时候，加上如下-D参数就能跳过测试。
$mvn clean install -Dmaven.test.skip=true
参数-D是Java自带的，其功能是通过命令行设置一个Java系统属性，Maven简单的重用了该参数，在准备插件的时候检查系统属性，便实现了插件参数的配置。
（1）假设没有带参数
C:UsersHermionereclipse-workspacehello>mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ---------------------------< com.test:hello >--------------------------- [INFO] Building hello 0.0.1-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hello --- [INFO] Deleting C:UsersHermionereclipse-workspacehello arget [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory C:UsersHermionereclipse-workspacehellosrcmain esources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 1 source file to C:UsersHermionereclipse-workspacehello argetclasses [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory C:UsersHermionereclipse-workspacehellosrc est esources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 1 source file to C:UsersHermionereclipse-workspacehello arget est-classes [WARNING] /C:/Users/Hermioner/eclipse-workspace/hello/src/test/java/com/test/hello/HelloWorldTest.java: C:UsersHermionereclipse-workspacehellosrc estjavacom esthelloHelloWorldTest.java uses or overrides a deprecated API. [WARNING] /C:/Users/Hermioner/eclipse-workspace/hello/src/test/java/com/test/hello/HelloWorldTest.java: Recompile with -Xlint:deprecation for details. [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello --- [INFO] Surefire report directory: C:UsersHermionereclipse-workspacehello argetsurefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.test.hello.HelloWorldTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello --- [INFO] Building jar: C:UsersHermionereclipse-workspacehello argethello-0.0.1-SNAPSHOT.jar [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ hello --- [INFO] Installing C:UsersHermionereclipse-workspacehello argethello-0.0.1-SNAPSHOT.jar to C:UsersHermioner oolsmavenmaven-repositorycom esthello0.0.1-SNAPSHOThello-0.0.1-SNAPSHOT.jar [INFO] Installing C:UsersHermionereclipse-workspacehellopom.xml to C:UsersHermioner oolsmavenmaven-repositorycom esthello0.0.1-SNAPSHOThello-0.0.1-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.503 s [INFO] Finished at: 2019-01-11T15:17:14+08:00 [INFO] ------------------------------------------------------------------------
说明：看上面的绿色部分，其实可以发现有8个阶段。各个插件的执行顺序一般是：clean，resources，compile，testResources，testCompile，test，jar，install。
在图中标记的地方每一行都是由冒号分隔的，前半部分是对应的插件，后半部分是插件的执行目标也就是插件执行产生的结果。同时还可以知道一些东西编译后放在了什么地方的。
（2）带了参数
C:UsersHermionereclipse-workspacehello>mvn clean install -Dmaven.test.skip=true [INFO] Scanning for projects... [INFO] [INFO] ---------------------------< com.test:hello >--------------------------- [INFO] Building hello 0.0.1-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hello --- [INFO] Deleting C:UsersHermionereclipse-workspacehello arget [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory C:UsersHermionereclipse-workspacehellosrcmain esources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 1 source file to C:UsersHermionereclipse-workspacehello argetclasses [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello --- [INFO] Not copying test resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello --- [INFO] Not compiling test sources [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello --- [INFO] Tests are skipped. [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello --- [INFO] Building jar: C:UsersHermionereclipse-workspacehello argethello-0.0.1-SNAPSHOT.jar [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ hello --- [INFO] Installing C:UsersHermionereclipse-workspacehello argethello-0.0.1-SNAPSHOT.jar to C:UsersHermioner oolsmavenmaven-repositorycom esthello0.0.1-SNAPSHOThello-0.0.1-SNAPSHOT.jar [INFO] Installing C:UsersHermionereclipse-workspacehellopom.xml to C:UsersHermioner oolsmavenmaven-repositorycom esthello0.0.1-SNAPSHOThello-0.0.1-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.518 s [INFO] Finished at: 2019-01-11T15:21:28+08:00 [INFO] ------------------------------------------------------------------------
2.3.2 在pom中插件全局配置
并不是所有的插件参数都适合从命令行配置，有些参数的值从项目创建到项目发布都不会改变，或者说很少改变，对于这种情况，在POM文件中一次性配置就显然比重负在命令行输入要方便。
用户可以在声明插件的时候，对此插件进行一个全局配置。也就是说，所有该基于该插件目标的任务，都会使用这些配置。例如我们通常会需要配置maven-compiler-plugin告诉它配置Java1.5版本的源文件，生成与JVM1.5兼容的字节码文件，代码如下：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artfactId>
<version>2.1</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configration>
</plugin>
</plugins>
</build>
这样，不管绑定到compile阶段的maven-compiler-plugin:compile任务，还是绑定到test-compiler阶段的maven-compiler-plugin：testCompiler任务，这都能够使用该配置，基于Java1.5版本进行编译。
2.3.3 pom中插件任务配置
除了为插件配置全局的参数，用户还可以为某个插件任务配置特定的参数。以maven-antrun-plugin为例，它有一个目标run,可以用来在Maven中调用Ant任务。用户将maven-antrun-plugin:run绑定到多个生命周期阶段上，再加以不同的配置，就可以让Maven在不同的生命周期执行不同的任务，代码如下:
1 <build> 2 <plugins> 3 <groupId>org.apache.maven.plugins<groupId> 4 <artifactId>maven-antrun-plugin</artifactId> 5 <version>1.3</version> 6 <executions> 7 <execution> 8 <id>ant-validate</id> 9 <phase>validate<phase> 10 <goals> 11 <goal>run</goal> 12 </goals> 13 <configuration> 14 <tasks> 15 <echo>Im'bound to validate phase</echo> 16 </tasks> 17 </configurationo> 18 </execution> 19 <execution> 20 <id>ant-verify</id> 21 <phase>verify</phase> 22 <goals> 23 <goal>run</goal> 24 </goals> 25 <configuration> 26 <tasks> 27 <echo>I'm bound to verify phase</echo> 28 </tasks> 29 </configuration> 30 </execution> 31 </executions> 32 </plugins> 33 </build>
上述代码片段中，首先，maven-antrun-plugin:run与validate绑定，从而构成一个id为ant-validate的任务。插件全局配置中的configuration元素位于plugin元素下面，而这里的configuration元素则位于execution元素下，表示这是特定任务的配置，而非插件整体的配置。这个ant-validate任务配置了一个echo Ant任务，向命令行输出一段文字，表示该任务是绑定到validate阶段的。第二个任务的id为ant-verify，它绑定到了verify阶段，同样它也输出一段文字到命令行，告诉该任务绑定到了verify阶段。
2.4 获取插件信息
仅仅理解如何配置和使用插件是不够的，当遇到一个构建任务的时候，用户还需要知道去哪里寻找合适的插件，以帮助完成任务，找到正确的插件之后，还要详细了解该插件的配置点。由于Maven的插件非常多，这其中大部分没有完善文档，因此，使用正确的插件并进行正确的配置，其实并不是一件容易的事。
2.4.1 在线插件信息
基本所有的主要的Maven插件都来自Apache和Codehaus。由于Maven本身是属于Apache软件基金会的，因此他有很多的官方的插件，每天都有成千上万的Maven用户在使用这些插件，他们具有非常好的的稳定性。详细的列表可以在这个地址得到：http://maven.apache.org/plugins/index.html，单击某个插件的链接便可以得到进一步的信息。所有的官方插件都可以在这里下载：http://repo1.maven.org/maven2/org/apache/maven/plugins
2.4.2 使用maven-help-plugin描述插件
除了访问在线的插件文档之外，还可以借助maven-help-plugin来获取插件的详细信息。。可以运行一下命令来获取maven-compiler-plugin2.1版本的信息：
$ mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin:2.1这里执行的是maven-help-plugins的describe目标，在参数的plugin中输入需要描述插件的groupId、artfactId和version。Maven在命令行输出maven-compiler-plugin的简要信息。
在描述插件的时候，还可以省去版本信息，让Maven自动获取最新版本来进行表述。例如：
$ mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin进一步简化，可以使用插件目标前缀替换坐标。例如：
$ mvn help:describe -Dplugin=compiler如果仅仅想描述某个插件目标的信息，可以加上goal参数：
$ mvn help:describe -Dplugin=compiler-Dgoal=compile如果想让maven-help-plugin输出更详细的信息，可以加上detail参数：
$ mvn help:describe -Dplugin=compiler-Ddetail
比如：
2.4.3 从命令行调用插件
如果在命令行运行mvn -h来显示mvn命令帮助。
2.5 插件解析机制
2.5.1 插件仓库
需要注意的是，Maven会区别对待依赖的远程仓库与插件的远程仓库。前面提到如何配置远程仓库，但是这种配置只对一般依赖有效果，当Maven需要的依赖在本地仓库不存在时，它会去所配置的远程仓库中查找，可是当Maven需要的插件在本地仓库不存在时，他就不会去那些远程仓库查找。
不同于repositories及其repository子元素，插件的远程仓库使用pluginRepositories和pluginReposirory配置，例如，Maven内置了如下的插件远程仓库配置,代码如下：
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository</name>
<url>http://repo1.maven.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
<snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>
除了pluginRepositories、pluginRepository不同外，其余与依赖远程仓库的配置完全一样。
一般来说，中央仓库所包含的插件完全能够满足我们的需要，因此也不需要配置其他的插件仓库。只有在很少的情况下，项目使用的插件无法在中央仓库找到，或者自己编写的插件，这个时候可以参考上述的配置，在POM或者settings.xml中加入其他的插件仓库配置。
2.5.2 解析插件版本
同样是为了简化插件的配置和使用，在用户没有提供插件版本的情况下，Maven会自动解析插件版本。
首先，Maven的超级POM中为所有核心插件设定了版本,超级POM是所有Maven项目的父POM，所有项目都会继承这个超级POM配置，因此，即使用户不加任何配置，Maven使用核心插件的时候，他们的版本都已经确定了，这些插件包括maven-clean-plugin、maven-compiler-plugin、maven-surefire-plugin等。
如果用户使用某个插件时没有设定版本，而这个插件又不属于核心插件范畴，Maven就会去检查所有仓库中的可用版本，然后做出选择。以maven-compiler-plugin为例，他在中央仓库的仓库元数据为：http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata.xml,其内容如下：
<?xml version="1.0" encoding="UTF-8"> <metadata> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <versioning> <latest>2.1</latest> <release>2.1</release> <versions> <version>2.0-beta-1</version> <version>2.0</version> <version>2.0.1</version> <version>2.0.2</version> <version>2.1</version> </versions> <lastUpdated>20100102092331</lastUpdated> </versioning> </metadata>
Maven遍历本地仓库和所有远程插件仓库，将该路径下的仓库元数据归并后，就能计算出latest和release的值。latest表示所有仓库中该构件的最新版本，而release表示最新的非快照版本。在Maven2中，插件的版本会被解析至latest。也就是说，当用户使用某个非核心插件且没有声明版本的时候，Maven会将版本解析为所有可用仓库中的最新版本，而这个版本也可能是快照版本的。
当插件的版本为快照版本的时，就会出现潜在的问题。Maven会基于更新策略，检查并使用快照的更新。某个插件可能昨天还好好的，今天就出错了。其原因是因为这个版本的插件发生了变化，为了防止这类问题，Maven3调整了解析机制，当插件没有声明版本的时候，不再解析至latest，而是使用release。这样就可以避免由于快照频繁更新而导致的插件行为不稳定。
依赖Maven解析插件版本其实是不推荐的做法，即使Maven3将版本解析到最新的非快照版本，也还是唯有潜在的不稳定性。例如，可能某个构件发布了一个新的版本，而这个版本的行为与之前的的版本发生了变化，这种变化就可能导致项目构建失败。因此，使用插件的时候，应该一直显式的设定版本，这也解释了Maven为什么要在超级POM中为核心插件设定版本。
参考文献
《Maven实战》
https://www.cnblogs.com/wangwei-beijing/p/6535081.html