生命周期和插件

Maven

除了坐标、依赖以及仓库之外，Maven 另外两个核心概念是生命周期和插件

在有关 Maven 的日常使用中，命令行的输入往往就对应了生命周期，如 mvn package 就表示执行默认生命周期阶段 package。Maven 的生命周期是抽象的，其实际行为都由插件来完成，如 package 阶段的任务可能就会由 maven-jar-plugin 完成。生命周期和插件两者协同工作，密不可分。

生命周期

Maven 拥有三套相互独立的生命周期，它们分别为 clean、default 和 site。clean 生命周期的目的是清理项目，default 生命周期的目的是构建项目，而 site 生命周期的目的是建立项目站点。

每个生命周期包含一些阶段（phase），这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，用户和 Maven 最直接的交互方式就是调用这些生命周期阶段。

较之于生命周期阶段的前后依赖关系，三套生命周期本身是相互独立的，用户可以仅仅调用 clean 生命周期的某个阶段，或者仅仅调用 default 生命周期的某个阶段，而不会对其他生命周期产生任何影响。

clean生命周期

clean 生命周期的目的是清理项目，它包含三个阶段：

1. pre-clean 执行一些清理前需要完成的工作
2. clean 清理上一次构建生成的文件
3. post-clean 执行一些清理后需要完成的工作

default生命周期

default 生命周期定义了真正构建时所需要执行的所有步骤，它是所有生命周期中最核心的部分，其包含的阶段如下，这里只对重要的阶段进行解释：

1. validate
2. initialize
3. generate-sources
4. process-sources：处理项目主资源文件。一般来说，是对 src/main/resources 目录的内容进行变量替换等工作后，复制到项目输出的主 classpath 目录中
5. generate-resources
6. process-resources
7. compile 编译项目的主源码。一般来说，是编译 src/main/java 目录下的 Java 文件至项目输出的主 classpath 目录中
8. process-classes
9. generate-test-sources
10. process-test-sources：处理项目测试资源文件。一般来说，是对 src/test/resources 目录的内容进行变量替换等工作后，复制到项目输出的测试 classpath 目录中
11. generate-test-resources
12. process-test-resources
13. test-compile：编译项目的测试代码。一般来说，是编译 src/test/java 目录下的 Java 文件至项目输出的测试 classpath 目录中
14. process-test-classes
15. test：使用单元测试框架运行测试，测试代码不会被打包或部署
16. prepare-package
17. package：接受编译好的代码，打包成可发布的格式，如 JAR
18. pre-integration-test
19. integration-test
20. post-integration-test
21. verify
22. install：将包安装到 Maven 本地仓库，供本地其他 Maven 项目使用
23. deploy：将最终的包复制到远程仓库，供其他开发人员和 Maven 项目使用

site生命周期

site 生命周期的目的是建立和发布项目站点，Maven 能够基于 POM 所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息。该生命周期包含如下阶段：

1. pre-site：执行一些在生成项目站点之前需要完成的工作
2. site：生成项目站点文档
3. post-site：执行一些在生成项目站点之后需要完成的工作
4. 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 的所有阶段。该命令结合了两个生命周期，在执行真正的项目构建之前清理项目是一个很好的实践。
• $ clean deploy site-deploy：该命令调用 clean 生命周期的 clean 阶段、default 生命周期的 deploy 阶段，以及 site 生命周期的 site-deploy 阶段。实际执行的阶段为 clean 生命周期的 pre-clean、clean 阶段，default 生命周期的所有阶段，以及 site 生命周期的所有阶段。该命令结合了 Maven 所有三个生命周期，且 deploy 为 default 生命周期的最后一个阶段，site-deploy 为 site 生命周期的最后一个阶段。

插件

Maven 的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构件形式存在，因此，Maven 核心的分发包只有不到 3MB 的大小，Maven 会在需要的时候下载并使用插件。

对于插件本身，为了能够复用代码，它往往能够完成多个任务。这些功能聚集在一个插件里，每个功能就是一个插件目标。maven-dependency-plugin 有十多个目标，每个目标对应了一个功能，上述提到的几个功能分别对应的插件目标为 dependency:analyze、dependency:tree 和 dependency:list。这是一种通用的写法，冒号前面是插件前缀，冒号后面是该插件的目标。

插件仓库

与依赖构件一样，插件构件同样基于坐标存储在 Maven 仓库中。在需要的时候，Maven 会从本地仓库寻找插件，如果不存在，则从远程插件仓库查找。找到插件之后，再下载到本地仓库使用。

Maven 会区别对待依赖的远程仓库与插件的远程仓库

不同于 repositories 及其 repository 子元素，插件的远程仓库使用 pluginRepositories 和 pluginRepository 配置，Maven 内置了插件远程仓库配置，可以在超级 POM 中看到：

<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <name>Central Repository</name>
        <url>https://repo.maven.apache.org/maven2</url>
        <layout>default</layout>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
        <releases>
            <updatePolicy>never</updatePolicy>
        </releases>
    </pluginRepository>
</pluginRepositories>

除了 pluginRepositories 和 pluginRepository 标签不同之外，其余所有子元素表达的含义与之前介绍的依赖远程仓库配置完全一样。这个默认插件仓库的地址就是中央仓库，它关闭了对 SNAPSHOT 的支持，以防止引入 SNAPSHOT 版本的插件而导致不稳定的构建。

插件绑定

Maven 的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。例如项目编译这一任务，它对应了 default 生命周期的 compile 这一阶段，而 maven-compiler-plugin 这一插件的 compile 目标能够完成该任务，因此将它们绑定就能实现项目编译的目的。

内置绑定

为了能让用户几乎不用任何配置就能构建 Maven 项目，Maven 在核心为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务。

clean 生命周期阶段与插件目标的绑定关系

site 生命周期阶段与插件目标的绑定关系

defaulte 生命周期阶段的内置插件绑定关系及具体任务（打包类型：jar）

自定义绑定

除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上，这种自定义绑定方式能让 Maven 项目在构建过程中执行更多更富特色的任务。

一个常见的例子是创建项目的源码 jar 包，内置的插件绑定关系中并没有涉及这一任务，因此需要用户自行配置。maven-source-plugin 可以帮助我们完成该任务，它的 jar-no-fork 目标能够将项目的主代码打包成 jar 文件（默认绑定到 default 生命周期的 package 阶段），将其绑定到 default 生命周期的 verify 阶段上，在执行完集成测试后和安装构件之前创建源码 jar 包。

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <version>3.0.1</version>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>jar-no-fork</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

在 POM 的 build 元素下的 plugins 子元素中声明插件的使用，除了基本的插件坐标声明外，还有插件执行配置，executions 下每个 execution 子元素可以用来配置执行一个任务。该例中配置了一个 id 为 attach-sources 的任务，通过 phase 配置，将其绑定到 verify 生命周期阶段上，再通过 goals 配置指定要执行的插件目标。至此，自定义插件绑定完成。当执行 verify 生命周期阶段的时候，maven-source-plugin:jar-no-fork 会得以执行。

有时候，即使不通过 phase 元素配置生命周期阶段，插件目标也能够绑定到生命周期中去。例如，可以尝试删除上述配置中的 phase 一行，再次执行 mvn verify，仍然可以看到 maven-source-plugin:jar-no-fork 得以执行。出现这种现象的原因是：有很多插件的目标在编写时已经定义了默认绑定阶段。

当插件目标被绑定到不同的生命周期阶段的时候，其执行顺序会由生命周期阶段的先后顺序决定。如果多个插件目标被绑定到同一个阶段，这些插件声明的先后顺序决定了目标的执行顺序。

插件配置

完成了插件和生命周期的绑定之后，用户还可以配置插件目标的参数，进一步调整插件目标所执行的任务，以满足项目的需求。几乎所有 Maven 插件的目标都有一些可配置的参数，用户可以通过命令行和 POM 配置等方式来配置这些参数。

命令行插件配置

很多插件目标的参数都支持从命令行配置，用户可以在 Maven 命令中使用 -D 参数，并伴随一个参数键 = 参数值的形式，来配置插件目标的参数。

例如，maven-surefire-plugin 提供了一个 maven.test.skip 参数，当其值为 true 的时候，就会跳过测试运行和跳过测试代码的编译。于是在运行命令的时候，加上如下 -D 参数就能跳过测试：

$ mvn package -Dmaven.test.skip=true

参数 -D 是 Java 自带的，其功能是通过命令行设置一个 Java 系统属性，Maven 简单地重用了该参数，在准备插件的时候检查系统属性，便实现了插件参数的配置。如果只需要跳过测试，那么使用 -DskipTests 即可

POM中插件全局配置

并不是所有的插件参数都适合从命令行配置，有些参数的值从项目创建到项目发布都不会改变，或者说很少改变，对于这种情况，在 POM 文件中一次性配置就显然比重复在命令行输入要方便。

例如，我们通常会需要配置 maven-compiler-plugin 告诉它编译 Java 1.8 版本的源文件，生成与 JVM 1.8 兼容的字节码文件：

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.3</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

这样，不管绑定到 compile 阶段的 maven-compiler-plugin:compile 任务，还是绑定到 test-compiler 阶段的 maven-compiler-plugin:testCompiler 任务，就都能够使用该配置，基于 Java 1.8 版本进行编译。

POM中插件任务配置

除了为插件配置全局的参数，用户还可以为某个插件任务配置特定的参数。以 maven-antrun-plugin 为例，它有一个目标 run，可以用来在 Maven 中调用 Ant 任务。用户 将maven-antrun-plugin:run 绑定到多个生命周期阶段上，再加以不同的配置，就可以让 Maven 在不同的生命阶段执行不同的任务：

<project>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>1.8</version>
                <executions>
                    <execution>
                        <id>ant-validate</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <tasks>
                                <echo>I'm bound to validate phase.</echo>
                            </tasks>
                        </configuration>
                    </execution>
                    <execution>
                        <id>ant-verify</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <tasks>
                                <echo>I'm bound to verify phase.</echo>
                            </tasks>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

在上述代码片段中，首先，maven-antrun-plugin:run 与 validate 阶段绑定，从而构成一个 id 为 ant-validate 的任务。插件全局配置中的 configuration 元素位于 plugin 元素下面，而这里的 configuration 元素则位于 execution 元素下，表示这是特定任务的配置，而非插件整体的配置。这个 ant-validate 任务配置了一个 echo Ant 任务，向命令行输出一段文字，表示该任务是绑定到 validate 阶段的。第二个任务的 id 为 ant-verify，它绑定到了 verify 阶段，同样它也输出一段文字到命令行，告诉该任务绑定到了 verify 阶段。

解析插件

为了方便用户使用和配置插件，Maven 不需要用户提供完整的插件坐标信息，就可以解析得到正确的插件，Maven 的这一特性是一把双刃剑，虽然它简化了插件的使用和配置，可一旦插件的行为出现异常，用户就很难快速定位到出问题的插件构件。例如 mvn help:system 这样一条命令，它到底执行了什么插件？该插件的 groupId、artifactId 和 version 分别是什么？这个构件是从哪里来的？接下来将详细介绍 Maven 的运行机制，以让读者不仅知其然，更知其所以然。

在 POM 中配置插件的时候，如果该插件是 Maven 的官方插件（即如果其 groupId 为 org.apache.maven.plugins），就可以省略 groupId 配置

在用户没有提供插件版本的情况下，Maven 会自动解析插件版本 version。

<metadata>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <versioning>
        <latest>3.0.2</latest>
        <release>3.0.2</release>
        <versions>
            <!-- too many ignore -->
            <version>2.5</version>
            <version>2.6</version>
            <version>3.0.0</version>
            <version>3.0.1</version>
            <version>3.0.2</version>
        </versions>
        <lastUpdated>20160622194305</lastUpdated>
    </versioning>
</metadata>

1. Maven 在超级 POM 中为所有核心插件设定了版本，超级 POM 是所有 Maven 项目的父 POM，所有项目都继承这个超级 POM 的配置，因此，即使用户不加任何配置，Maven 使用核心插件的时候，它们的版本就已经确定了。
2. 如果用户使用某个插件时没有设定版本，而这个插件又不属于核心插件的范畴，Maven 就会去检查所有仓库中可用的版本，然后做出选择。Maven 遍历本地仓库和所有远程插件仓库，将该路径下的仓库元数据归并后，就能计算出 latest 和 release 的值，使用 release 版本。

插件前缀与 groupId:artifactId 是一一对应的，这种匹配关系存储在仓库元数据中。与之前提到的 groupId/artifactId/maven-metadata.xml 不同，这里的仓库元数据为 groupId/maven-metadata.xml，相应地，Maven 在解析插件仓库元数据的时候，会默认使用 org.apache.maven.plugins 的 groupId，也可以通过配置 settings.xml 让 Maven 检查其他 groupId 上的插件仓库元数据：

<settings>
    <pluginGroups>
        <pluginGroup>com.your.plugins</pluginGroup>
    </pluginGroups>
</settings>

基于该配置，Maven就不仅仅会检查 org/apache/maven/plugins/maven-metadata.xml 和 org/codehaus/mojo/maven-metadata.xml，还会检查 com/your/plugins/maven-metadata.xml。

下面看下 org/apache/maven/plugins/maven-metadata.xml 的元数据内容：

<metadata>
    <plugins>
        <!-- too many ignore -->
        <plugin>
            <name>Apache Maven Clean Plugin</name>
            <prefix>clean</prefix>
            <artifactId>maven-clean-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Apache Maven Compiler Plugin</name>
            <prefix>compiler</prefix>
            <artifactId>maven-compiler-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Apache Maven Javadoc Plugin</name>
            <prefix>javadoc</prefix>
            <artifactId>maven-javadoc-plugin</artifactId>
        </plugin>
    </plugins>
</metadata>

从这段数据中就能看到 maven-clean-plugin 的前缀为 clean，maven-compiler-plugin 的前缀为 compiler，maven-javadoc-plugin 的前缀为 javadoc。

当 Maven 解析到一个插件命令时，它首先基于默认的 groupId 归并所有插件仓库的元数据，如果 org/apache/maven/plugins/maven-metadata.xml 没有记录该插件前缀，则接着检查其他 groupId 下的元数据，如果所有元数据中都不包含该前缀，则报错。