Maven——生命周期与插件

1、生命周期详解

三套生命周期

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

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

三套生命周期本身是相互独立的，用户可以仅调用clean生命周期的某个阶段，或者仅仅调用default阶段的时候不会触发其他生命周期的任何阶段。

clean生命周期

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

• per-clean:执行一些清理前需要完成的工作。
• clean：清理上一次构建生成的文件。
• post-clean:执行一些清理后需要完成的工作。

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。

site生命周期

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

• pre-site:执行一些在生成项目站点之前需要完成的工作。
• site:生成项目站点文档。
• post-site:执行一些在生成项目站点之后需要完成的工作。
• site-deploy:将生成的项目站点发布到服务器上。

命令行与生命周期

从命令行执行Maven任务的最主要方式就是调用Maven生命周期阶段。需要注意的是，各个生命周期之间是相互独立的，而一个生命周期的阶段室友前后依赖关系的。下面以一下常用的Maven命令为例，解释其执行的生命周期阶段：

• $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的所有阶段。
• $mvn clean deploy site-deploy:该命令调用了clean生命周期的clean阶段、defalut生命周期的deploy阶段，以及site生命周期的site-deploy阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段，default生命周期的所有阶段和site生命周期的所有阶段。

2、插件目标

对于插件本身，为了能够复用代码，它往往能够完成多个任务。例如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目标）。

3、插件绑定

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

内置绑定

为了让用户不用做任何配置就能构建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

自定义绑定

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

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

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

在POM的build元素下的plugings子元素中声明插件的使用，该例中用到的是maven-source-plugin,其groupId为org.apache.maven.plugins,这也是Maven官方插件的groupId，紧接着artifactId为maven-source-plugin，version为2.1.1 对于自定义绑定的插件，用户总是应该声明一个非快照版本，这样可以避免由于插件版本变化造成的构件不稳定性。

上面配置中，除了基本的插件坐标声明外，还有插件执行配置，executions下每个execution子元素可以用来配置执行一个任务。该例中配置了一个id为attach-source的任务，通过phrase配置，将其绑定到verify生命周期阶段上，再通过goals配置指定要执行的插件目标。当运行mvn verify，maven-source-plugin：jar-no-fork会得以执行，它会创建一个以-sources.jar结尾的源码文件包。

4、插件配置

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

命令行插件配置

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

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

$mvn install -Dmaven.test.skip=true

参数-D是Java自带的，其功能是通过命令行设置一个Java系统属性，Maven简单的重用了该参数，在准备插件的时候检查系统属性，便实现了插件参数的配置。

在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版本进行编译。

POM中插件任务配置

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

<build>
    <plugins>
        <groupId>org.apache.maven.plugins<groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.3</version>
        <executions>
            <execution>
                <id>ant-validate</id>
                <phase>validate<phase>
                <goals>
                    <goal>run</goal>
                </goals>
                <configuration>
                    <tasks>
                        <echo>Im'bound to validate phase</echo>
                    </tasks>
                </configurationo>
            </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>
    </plugins>
</build>

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

5、获取插件信息

仅仅理解如何配置和使用插件是不够的，当遇到一个构建任务的时候，用户还需要知道去哪里寻找合适的插件，以帮助完成任务，找到正确的插件之后，还要详细了解该插件的配置点。由于Maven的插件非常多，这其中大部分没有完善文档，因此，使用正确的插件并进行正确的配置，其实并不是一件容易的事。

在线插件信息

基本所有的主要的Maven插件都来自Apache和Codehaus。由于Maven本身是属于Apache软件基金会的，因此他有很多的官方的插件，每天都有成千上万的Maven用户在使用这些插件，他们具有非常好的的稳定性。详细的列表可以在这个地址得到：http://maven.apache.org/plugins/index.html，单击某个插件的链接便可以得到进一步的信息。所有的官方插件都可以在这里下载：http://repo1.maven.org/maven2/org/apache/maven/plugins

使用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

从命令行调用插件

如果在命令行运行mvn -h来显示mvn命令帮助，可以看到如下的信息：

usage:mvn [options] [<goal(s)>] [<phase(s)>]
Options:
...

该信息告诉了我们mvn命令的基本用法，options表示可用的选项，mvn命令有20多个选项，除了选项之外，mvn命令后面可以添加一个或者多个goal和phase，他们分别是指插件目标和生命周期阶段

可以通过mvn命令激活生命周期阶段，从而执行那些绑定在生命周期阶段上的插件目标。但Maven还支持直接从命令行调用插件目标。Maven支持这种方式是因为有些任务不适合绑定在生命周期上，例如maven-help-plugin:describe，我们不需要在构建项目的时候去描述插件信息，又如maven-dependency-plugin:tree,我们也不需要在构建项目的时候去显示依赖树，因此这些插件目标应该通过如下方式使用：

$ mvn help:describe-Dplugin=compiler
$ mvn dependency:tree

不过这里有个疑问，describe是maven-help-plugin的目标没错，但是冒号前面的help是什么呢？它既不是groupId，也不是artifactId,Maven是如何根据该信息找到对应版本插件的呢？同理为什么不是maven-dependency-plugin:tree,而是dependency:tree

解答该疑问之前，可以尝试一下如下命令：

$ mvn org.apache.maven.plugins:maven-help-plugin:2.1:describe-Dplugin=compiler

$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:tree

这两条命令就比较容易理解了，插件的groupId、artifactId、version以及goal都得以清晰描述。它们的效果与之前的两条命令基本是一样的，但是显然前面的命令更简洁，更容易记忆和使用。为了达到该目的，Maven引入了目标前缀的概念help是maven-help-plugin的目标前缀，dependency是maven-dependency-plugin的前缀，有了插件前缀，Maven就能找到对应的artifactId。不过，除了artifactId,Maven还需要得到groupId和version才能精确定位到某个插件。

6、插件解析机制

插件仓库

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

需要注意的是，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中加入其他的插件仓库配置。

插件的默认groupId

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

上面省略了配置maven-compiler-plugin的groupId，Maven在解析该插件的时候，会自动用默认groupId org.apache.maven.plugins补齐。但是并不推荐使用Maven的这一机制，这样虽然可以省略一些配置，但是这样的配置会让团队中不熟悉Maven的成员感到费解，况且能省略的配置也就仅仅一行而已。

解析插件版本

同样是为了简化插件的配置和使用，在用户没有提供插件版本的情况下，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中为核心插件设定版本。

解析插件前缀

mvn命令行支持使用插件前缀来简化插件的调用，现在解释Maven如何根据插件前缀解析到插件的坐标的。

插件前缀与groupId:artifactId是一一对应的，这种匹配关系存储在仓库元数据中，与之前提到的groupId/artifactId/maven-metadata.xml不同，这里的仓库元数据为groupId/maven-metadata.xml,那么这里的groupId是什么呢？前面提到，主要的插件都位于http://repo1.maven.org/maven2/org/apache/maven/plugins/和http://repository.codehaus.org/org/codehaus/mojo,相应地，Maven在解析插件仓库元数据的时候，会默认使用org.apache.maven.plugins和org.codehaus.mojo两个groupId。也可以通过配置setting.xml让Maven检查其他groupId上的插件仓库元数据：

<settings>
    <plugins>
        <plugin>
            <name>Maven Clean Plugin</name>
            <prefix>clean</prefix>
            <artifactId>maven-clean-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Maven Compiler Plugin</name>
            <prefix>compiler</prefix>
            <artifactId>maven-compiler-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Maven Compiler Plugin</name>
            <prefix>compiler</prefix>
            <artifactId>maven-compiler-plugin</artifactId>
        </plugin>
        <plugin>
            <name>Maven Dependency Plugin</name>
            <prefix>dependency</prefix>
            <artifactId>maven-dependency-plugin</artifactId>
        </plugin>
    </plugins>
</settings>

上面内容是从中央仓库的org.apche.maven.plugins groupId下插件仓库元数据中截取的一些片段，从这段数据中可以看到，maven-clean-plugin的前缀为clean,maven-compiler-plugin的前缀为compiler,mavenp-dependency-plugin的前缀为dependency。

当Maven解析到dependency：tree这样的命令后，它首先基于默认的groupId归并所有插件仓库的元数据org/apache/maven/plugins/maven-metadata.xml;其次检查归并后的元数据，找到对应的artifactId为maven-dependency-plugin;然后结合当前元数据的groupId org.apache.maven.plugins按照解析插件版本的方法得到version,这时就得到了完整的插件坐标。如果org/apache/maven/plugins/maven-metadata.xml没有记录该插件前缀，则接着检查其他groupId下的元数据，如org/codehaus/mojo/maven-metadata.xml,以及用户自定义的插件组。如果所有元数据中都不包含该前缀，则报错。

转载自  maven-生命周期与插件