除了坐标、依赖以及仓库以外，maven另外两个核心概念就是生命周期和插件。maven的生命周期是抽象的，其实际行为都是由插件来完成。
7.1 什么是生命周期
在maven出现之前，项目构建的生命周期就已经存在，软件开发人员每天都在对项目进行清理、编译、测试以及部署。
Maven的生命周期就是为了对所有的构建过程进行抽象和统一。Maven从大量项目和构建工具中学习和反思，然后总结出一套高度完善的、易扩展的生命周期。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。也就是说，几乎所有项目的创建，都能映射到这样一个生命周期上。
Maven的生命周期是抽象的， 这意味着生命周期本身不做任何实际任务，在maven的设计中，实际的任务都交给插件来完成。这种思想与设计模式的模板方法（template method）非常相似。模板方法在父类中定义算法的整体结构，子类可以通过实现或者重写父类的方法来控制实际的行为，这样既保证了算法有足够的可扩展性，又能够严格控制算法的整体结构。如下的模板方法抽象类能够很好的体现maven生命周期的概念。
public abstract class AbstractBuild {
private AbstractBuild(){}
public void build() {
init();
compile();
test();
packagee();
integrationTest();
deploy();
}
/**
* 抽象方法 初始化
*/
protected abstract void init();
/**
* 抽象方法 编译
*/
protected abstract void compile();
/**
* 测试
*/
protected abstract void test();
/**
* 打包:因为package是关键词
*/
protected abstract void packagee();
/**
* 集成测试
*/
protected abstract void integrationTest();
/**
* 部署
*/
protected abstract void deploy();
}
这个类没有具体实现初始化，编译，测试等行为，它们都交由子类去实现。
虽然上述代码和Maven实际代码相去甚远，Maven的生命周期包含更多的步骤和更复杂的逻辑，但是它们的基本理念是相同的。为了不让用户重复发明轮子，Maven设计了插件机制。
每个构建步骤都可以绑定一个或多个插件行为，而且maven为大多数构建步骤编写并绑定了默认插件。例如，针对编译的插件有maven-compiler-plugin，针对测试的插件有maven-surefire-plugin等。当用户有特殊需要的时候，也可以配置插件定制构建行为，甚至自己编写插件。
maven定义的生命周期和插件机制一方面保证了所以Maven项目有一致的构建标准，另一方面又通过默认插件简化和稳定了实际项目的构建。此外，扩展性也不错。
7.2 生命周期详解
三套生命周期
Maven其实拥有三套相互独立的生命周期，他们分别为clean、default和site。clean生命周期的目的是清理项目，default生命周期的目的是构建项目，而site则是建立项目站点。
每个生命周期包含一些阶段（phase），这些阶段是有顺序的，且具有依赖的关系。
但是三套生命周期本身是相互独立的， 用户可以仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响。
clean生命周期
clean生命周期的目的是清理项目，它包含三个阶段：
- pre-clean：执行一些清理前需要完成的任务
- clean：清理上一次构建生成的文件
- post-clean：执行一些清理后需要完成的工作
default生命周期
default生命周期定义了真正构建时所需要的所有步骤，它是所有生命周期中最核心的部分。
- validate
- initialize
- generate-sources：
- process-sources：处理项目主资源文件。一般来说，是对
src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中。 - generate-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项目使用。
site生命周期
site生命周期的目的是建立和发布项目站点，maven能够基于pom所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息。该生命周期包括：
- pre-site：执行一些在生成项目站点之后需要完成的工作。
- site：生成项目站点文档。
- post-site：执行一些在生成项目站点之后需要完成的工作。
- site-deploy：将生成的项目站点发布到服务器上。
命令行与生命周期
以常见命令解释其执行的生命周期阶段：
$mvn clean：该命令调用clean生命周期的clean阶段。实际执行的阶段为clean生命周期的pre-clean和clean阶段。$mvn test：该命令调用default生命周期的test阶段。实际执行的阶段为default生命周期的validate、initialize等，直到test的所有阶段。这也解释了为什么在执行测试的时候，项目的代码能够自动得以编译。$mvn clean install：该命令调用clean生命周期的clean阶段和default生命周期的install阶段。实际执行的阶段为clean生命周期的pre-clean和clean阶段，以及default生命周期从validate到install的全部阶段。该命令结合了两个生命周期，在执行正在的项目构建之前清理项目是一个很好的实践。
7.3 插件目标
Maven的核心仅仅定义了抽象的生命周期，具体的任务是交给插件完成的，插件以独立的构件形式存在，因此，maven核心的分发包只有3MB，Maven会在需要的时候下载并使用插件。
maven-dependency-plugin有十多个目标，每个目标对应一个功能，上述提到的几个功能分别对应dependency:analyze，dependency:tree和dependency:list。
冒汗前面是插件前缀，冒号后面是该插件的目标。
类似的还有:surefire:test这个是maven-surefile-plugin的test目标。
7.4 插件绑定
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。
内置绑定
为了能让用户几乎不用任何配置就能构建Maven项目，Maven在核心为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务。
clean生命周期仅有的pre-clean、clean和post-clean三个阶段，其中的clean与maven-clean-plugin:clean绑定。
自定义绑定（重点）
除了内置绑定以外，用户还能够自己选择将某个插件绑定到生命周期的某个阶段，这种自定义绑定方法能让maven项目在构建过程中执行更多任务。
一个常见的例子是创建项目的源码jar包，内置的插件绑定关系中并没有涉及这一任务，因此需要用户自行配置。maven-source-plugin可以帮助我们完成该任务，它的jar-no-fork目标能够将项目的主代码打包成jar文件。
<build>
<plugins>
<plugin>
<GAV/>
<executions>
<execution>
<id>task1</id>
<phase>varify</phase>
<goals>
<goal/>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
在POM的build元素下的<plugins>字元素中声明插件的使用。对于自定义绑定的插件，用户总是应该声明一个非快照版本，这样可以避免由于版本变化造成的构建不稳定性。
在上述配置中，除了基本的插件坐标声明外，还有插件执行配置，<executions>下每个execution资源时可以用来配置执行一个任务。该例子中配置了一个id为task1的任务，通过phrase配置，将其绑定到verify声明周期阶段上，再通过goals配置指定要执行的插件目标。至此，自定义插件绑定完成。运行mvn verify就能看到如下输出。
我们知道，当插件目标被绑定到不同的生命周期阶段的时候，其执行顺序会由生命周期阶段的先后顺序决定。如果多个目标被绑定到同一个阶段，这些插件声明的先后顺序决定了目标的执行顺序。
7.5 插件配置
完成了插件和生命周期的绑定之后，用户还可以配置插件目标的参数，进一步调整插件目标所执行的任务，以满足项目的需求。
命令行插件配置
用户可以在maven命令中使用-D参数，并伴随一个参数键=参数值的形式来配置插件目标的参数。
比如在maven-surefile-plugin中提供了maven.test.skip参数：
mvn install -Dmaven.test.skip=true
-D是用来在启动一个java程序时设置系统属性值的。如果该值是一个字符串且包含空格，那么需要包在一对双引号中。
POM中插件全局配置
用户可以在声明插件的时候，对此插件进行一个全局的配置。例如我们需要配置maven-compiler-plugin告诉它编译Java 1.5版本的源文件，生成与JVM1.5兼容的字节码：
<build>
<plugins>
<plugin>
<groupId>org.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
这样，不管绑定到compile阶段的maven-compiler-plugin:compile任务，还是绑定到test-compiler阶段的maven-compiler-plugin:testCompiler任务，就都能够使用该配置，基于1.5版本进行编译。
POM中插件任务配置
略
7.6 获取插件信息
在线插件信息
基本上所有主要的maven插件都来自Apache和codehaus
网址：https://maven.apache.org/plugins/index.html
托管于Codehaus上的Mojo项目也提供了大量maven插件。但是该网址已经关停了。
使用maven-help-plugin描述插件
mvn help:describe -Dplugin = org.apache.maven.plugins:maven-compiler-plugin:2.1
执行了maven-help-plugin的describe目标。在参数plugin中输入需要描述插件的GAV。
【略】
常见插件
| 插件名称 | 用于 | 来源 |
|---|---|---|
| maven-clean-plugin | ||
| maven-compiler-plugin | ||
| deploy | ||
| install | ||
| resources | 处理资源文件 | |
| maven-site-plugin | 生成站点 | |
| maven-surefire-plugin | 执行测试 | |
| maven-jar-plugin | 构建jar | |
| maven-javadoc-plugin | 生成javadoc文档 | |
| maven-pmd-plugin | 生成PMD报告 | |
| maven-assembly-plugin | 构建自定义格式的分发包 | |
| maven-enforcer-plugin | 定义规则并强制要求项目遵循 | |
| maven-source-plugin | 生成源码包 | |
| properties-maven-plugin | 从properties文件读写maven属性 | |
| jetty-maven-plugin | 集成Jetty容器，实现快速开发测试 |
7.8 插件解析机制
为了方便用户使用和配置插件，maven不需要用户提供完整的插件坐标信息，就可以解析得到正确的插件，maven的这一特性是一把双刃剑，虽然它简化了插件的使用和配置，可一旦插件的行为出现异常，用户就很难快速定位到出现问题的构建。比如
mvn help:system
这一条命令，它到底执行了什么插件？下面介绍原理。
插件仓库
与依赖构件一样，插件构件同样基于坐标存储在maven仓库中。在需要的时候，maven会从本地查找，如果没有去远程操作找。
但是maven会区别对待依赖的远程仓库和插件的远程仓库。当maven需要的依赖在本地仓库不存在时，它会去所配置的远程仓库查找，可是当maven需要的插件在本地仓库不存在时，它就不会去这些远程仓库查找。
插件的远程仓库使用pluginRepositories和pluginRepository配置。
插件的默认groupId
在POM中配置插件的时候，如果该插件是maven的官方插件，就可以忽略groupId配置。
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>
上述配置就省略了groupId，maven在解析该插件的时候，会自动用默认groupId：org.apache.maven.plugins补齐。【不推荐】
解析插件版本
同样是为了简化插件的配置和使用，在用户没有提供版本的情况下，maven会自动解析插件版本。
首先，maven在超级POM中为所有核心插件设定了版本，超级POM是所有maven项目的父POM。所有项目都继承这个超级POM配置。因此，即使用户不加任何配置，maven使用核心插件的时候，它们的版本就已经确定了。
如果用户使用某个插件时，没有设定版本，而这个插件又不属于核心插件的范畴，maven就会去检查所有仓库中可用的版本，然后做出选择。
maven遍历本地仓库和所有远程插件仓库，将该路径下的仓库元数据归并后，就能计算出latest和release的值。然后使用release而不是latest，避免由于快照频繁更新导而导致的插件行为不稳定。
【但是不设定版本是不推荐的， 同样超级POM中为核心插件已经设定了版本】
解析插件前缀
插件前缀与groupId:artifactoryId是一一对应的，这种匹配关系存储在仓库元数据中。与依赖的groupId/artifactoryId/maven-metadata.xml不同，这里的仓库元数据为groupId/maven-metadata.xml。
Maven在解析插件仓库元数据的时候，会默认使用org.apache.maven.plugins和org.codehaus.mojo两个groupId。
也可以通过配置settings.xml让maven检查其他groupId上的插件仓库元数据：
<settings>
<pluginGroups>
<pluginGroup>com.ssozh.plugins</pluginGroup>
</pluginGroups>
</settings>
基于该配置，maven就不仅仅会检查这两个地方的xml了。还会检查com/ssozh/plugins/maven-metadata.xml。
<metadata>
<plugins>
<plugin>
<name>Maven Dependency Plugin</name>
<prefix>dependency</prefix>
<artifactId>mavne-dependency-plugin</artifactId>
</plugin>
</plugins>
</metadata>
上述内容中可以看出，当Maven解析到dependency:tree这样的命令的时候，它首先基于默认的groupId归并所有插件仓库的元数据，其次检查归并后的元数据，找到对应的artifactId。然后结合当前元数据的groupId。最后使用上述方法获取version。这时就得到了完整的插件坐标。
如果该maven-metadata.xml没有记录该插件前缀，就去mojo然后去自定义，如果都没有，则报错。
7.9 小结
本章介绍了maven的生命周期和插件这两个重要的概念。不仅解释了生命周期背后的理念，还详细阐述了clean、default、site三套生命周期各自的内容。此外，本章还重点介绍了maven插件如何与生命周期绑定，以及如何配置插件行为，如何获取插件信息。
补充
generate-source：