翻译自http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
目录
- 目录
- 生成生命周期基础
- 生成生命周期由阶段组成
- 通用命令行调用
- 一个生成阶段是由插件目标组成
- 某些阶段通常不从命令行调用
- 设置项目以使用生成生命周期
- 生命周期参考
- 内置生命周期绑定
生成生命周期基础
Maven是基于生成生命周期这一核心概念的。这意味着生成和分配特定组件（项目）的过程是有明确定义的。
对于项目生成者而言，这意味着为了能够生成Maven项目，学习一系列命令是必要的，项目目标模型（POM）可以确保他们获得他们想要的结果。
有三个内置的生成生命周期：默认（default），清空（clean），站点（site）。default生命周期处理项目部署，clean生命周期处理项目清空，site生命周期处理项目站点文档的创建。
生成生命周期由阶段组成
每一个组件的生命周期是依据不同生成阶段的清单所定义，清单中的每一个生成阶段是生命周期的一部分。
例如，默认生命周期包括以下阶段（对于生命周期阶段的完整列表，请参照生命周期参考）：
validate - 验证项目是正确的，所有必要的信息是可用的compile - 编译项目的源代码test - 使用合适的单元测试框架测试编译后的源代码。这些测试不需要打包或部署源码package - 将已编译的代码封装成可发布的格式，如JAR包verify - 运行任何对集成测试结果的检查，以确保达到质量标准install - 将包安装到本地储存库中，以便在其他项目中用作本地的依赖项deploy - 在生成环境中完成部署，将最终包复制到远程存储库，以便与其他开发人员及项目共享。
这些生命周期阶段（加上其他生命周期阶段没有显示在这里）顺序执行，以完成default生命周期。上述所给出的周期阶段意味着当默认生命周期运行时，Maven将首先验证项目，然后将尝试编译源代码，运行针对包和二进制文件（如JAR）的测试，针对整个包运行集成测试，验证集成测试，安装已验证的包到本地储存库，然后将安装包部署至远程存储库。
通用命令行调用
在开发环境中，使用下面的调用在本地存储库中生成和安装构件。
mvn install
在执行此命令前，即在执行install前，每个默认生命周期阶段（validate，complile，package等）都将被依次执行。您只需要调用最后一个生成阶段来执行，在这种情况下即为，install；
在生成环境中，使用下面的调用可以清空已有生成并部署构件至共享存储库中。
mvn clean deploy
同样的命令可以用在多模块的情况下（即一个项目包含一个或一个以上子项目）。Maven将进入每个子项目执行clean，然后执行deploy（包括所有现有的生成阶段的步骤）。
一个生成阶段是由插件目标组成
然而，即使是由生成阶段负责生成生命周期中的特定步骤，但执行这些职能的方式可能会有所不同。这是通过声明绑定到这些生成阶段的插件目标来实现的。
插件目标代表一个特定的任务（比生成阶段更精细），它有助于项目的建立和管理。它可以绑定到零或更多的生成阶段。未绑定到任何生成阶段的目标可以通过直接调用使其在生成生命周期之外执行。执行顺序取决于目标和生成阶段的调用顺序。例如，考虑下面的命令。clean和package参数属于生成阶段一级，而dependency:copy-dependency是目标（插件目标）级。
mvn clean dependency:copy-dependencies package
在执行时，clean阶段将首先执行（这意味着它将运行clean之前的所有的阶段，加上clean阶段自身），然后执行dependency:copy-dependencies目标，最后执行package阶段（和在其之前默认生命周期的生成阶段）。
此外，如果一个目标被绑定到一个或多个生成阶段，这个目标将在所有这些阶段都将被调用。
此外，一个生成阶段也可以有零个或多个目标绑定到它。如果生成阶段没有与它绑定的目标，则生成阶段不会执行。但如果它有一个或多个目标，它将执行所有这些目标
（注：在Maven 2.0.5以上，多目标绑定到一个阶段都是以他们在POM声明的顺序执行，但不支持相同插件的多个实例。但是，相同插件的多个实例在Maven 2.0.11以上可以被分组排序后共同执行）
某些阶段通常不从命令行调用
以前缀词命名的阶段（pre-*，post-*，或process-*）通常不是从命令行直接调用。这些阶段安排生成顺序，生成不被生成过程外所用的中间结果。如在调用integration-test的情况下，环境可能以挂起状态终止。
代码覆盖工具如Jacoco和执行容器插件如Tomcat，Cargo，Docker绑定目标至pre-integration-test阶段以准备集成测试容器环境。这些插件也绑定目标至post-integration-test以收集覆盖统计结果或使用完毕的集成测试容器。
故障和代码覆盖插件绑定目标在integration-test和verify阶段。最终结果测试和覆盖报告在verify阶段后可用。如果从命令行调用integration-test，则不生成报告。更糟糕的是，集成测试容器的环境会以挂起状态终止；Tomcat网络服务器或Docker实例会终止运行，而Maven可能不会自行终止。
设置项目以使用生成生命周期
生成生命周期的使用较为简单，但是当制作一个Maven生成项目时，该如何分配任务的各个生成阶段？
封包
最常见的方式，是通过有同样命名的POM元素<packaging>来设置封包。一些有效的封包方式有jar，war，ear和pom。如果没有指定封包格式，它将默认为JAR。
每个封包包含着一系列目标以绑定一个阶段。如，jar封包将绑定如下目标至默认生命周期中的生成阶段
| 生成阶段 | 目标 |
|---|
process-resources | resources:resources |
compile | compiler:compile |
process-test-resources | resources:testResources |
test-compile | compiler:testCompile |
test | surefire:test |
package | jar:jar |
install | install:install |
deploy | deploy:deploy |
这是一个近乎标准的绑定设置；然而，一些封包采用不同方式处理。例如，一个项目，是纯粹的元数据（封包方式是POM）只绑定目标至install和deploy阶段（因为一个完整的目标-生成阶段清单已经绑定了一些封包类型、参见生命周期参考）。
值得注意的是为了使一些封包类型可用，您可能还需要在POM中的<build>模块包含特定插件，并且为该插件制定<extensions>true</extensions>。需求这个的一个插件例子是Plexus插件，它提供了一个plexus-application和plexus-service封包。
插件
第二种将目标添加到阶段的方法是在项目中配置插件。插件是为Maven提供目标的元件。此外，插件可能有一个或多个目标，其中每个目标代表插件的一个功能。例如，编译器插件有两个目标：compile和testcompile。前者编译主要代码的源码，而后者编译测试代码的源码。
正如您将在后面的部分看到的，插件可以包含可绑定目标的生命周期阶段的指示信息。请注意，仅添加插件本身是信息不足的-您还必须指定作为你的生成中想运行的目标。
被配置的目标将被添加到从在封包选择时已绑定至生命周期的目标中。如果有多个目标绑定到一个特定的阶段，执行的顺序是首先是封包中的目标，其次是配置在POM中的目标。请注意，您可以使用<executions>元素以获得对特定目标顺序的更多控制权。
例如，Modello插件默认绑定目标modello:java至generate-sources阶段（注：modello:java目标生成Java源码）。所以为使用Modello插件和用它从模型生成源码并将其包含入生成之中，你需要将以下部分添加至POM里<build>中的<plugins>阶段：
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.8.1</version>
<executions>
<execution>
<configuration>
<models>
<model>src/main/mdo/maven.mdo</model>
</models>
<version>4.0.0</version>
</configuration>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
你也许困惑为何<execution>元素在那里。这是因为通过这样才能用不同配置运行多次相同目标。拆分的执行也可以被给予一个ID，以便在继承或应用概况中，您可以控制目标设置是否合并或产生额外的执行。
当有多个属于同一阶段的执行时，他们将按POM中指定的顺序执行，被继承的执行优先运行。
以modello:java为例，它只在generate-sources阶段有效。但是一些目标可以在多个阶段使用，并且可能没有一个明确的默认设置。对于这些目标，你可以自行指定阶段。例如，假设你有一个目标display:time，它会将当前时间反馈到命令行，如果你想要它运行在process-test-resources阶段以表明当测试开始的时间。这将配置如下：
<plugin>
<groupId>com.mycompany.example</groupId>
<artifactId>display-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>process-test-resources</phase>
<goals>
<goal>time</goal>
</goals>
</execution>
</executions>
</plugin>
生命周期参考
以下列出了default、clean和site生命周期的所有生成阶段，他们按照给定的点顺序执行。
Clean生命周期
| 阶段 | 说明 |
|---|
pre-clean | 在实际项目清理之前执行所需的过程 |
clean | 删除之前生成的所有文件 |
post-clean | 执行完成项目清理所需的过程 |
Default生命周期
| 阶段 | 说明 |
|---|
validate | 验证项目是否正确，所有必要的信息是否可用 |
initialize | 初始化生成状态，例如设置属性或创建目录 |
generate-sources | 为编译引用生成所有源代码 |
process-sources | 处理源代码，例如过滤某些值 |
generate-resources | 为包中的引用生成资源 |
process-resources | 将资源复制至目标地址并处理，以备打包 |
compile | 编译工程源代码 |
process-classes | 编译过程后处理生成文件，例如对Java类做字节码增强 |
generate-test-sources | 为编译引用生成测试源代码 |
process-test-sources | 处理测试源代码，例如过滤某些值 |
generate-test-resources | 为测试生成资源 |
process-test-resources | 复制资源至测试目标目录并处理 |
test-compile | 编译测试源代码至测试目标目录 |
process-test-classes | 测试编译过程后处理生成文件，例如对Java类做字节码增强。需要Maven 2.0.5以上 |
test | 使用合适的单元测试框架运行测试，这些测试不应当要求代码已打包或已部署 |
prepare-package | 在实际封包前执行所有必要的准备工作，这经常产生原包的未打包、已加工版本(需要Maven 2.1及以上) |
pre-integration-test | 在集成测试前执行所需操作，这也许会涉及设置需求环境等操作 |
integration-test | 处理并且部署（如果需要）包至集成测试可运行的环境 |
post-integration-test | 在集成测试后执行所需操作，这可能包括清理环境 |
verify | 运行检查以确保包可用并且达到质量标准 |
install | 将包安装至本地资源库中，使得其他工程可将其作为本地依赖项使用 |
deploy | 在集成或发布环境中完成，将最终包复制到远程存储库，以便与其他开发人员和项目共享 |
Site生命周期
| 阶段 | 说明 |
|---|
pre-site | 在实际项目站点生成之前执行所需的过程 |
site | 生成项目的站点文件 |
post-site | 执行完成网站生成所需的流程，并为网站部署做准备 |
site-deploy | 将生成的站点文档部署到指定的web服务器 |
内置生命周期绑定
有些阶段有默认与其绑定的目标。对于默认生命周期，这些绑定取决于封包值。以下是指向生成阶段目标的绑定情况。
clean生命周期绑定
default生命周期绑定 - 封包格式ejb / ejb3 / jar / par / rar / war
| 生命周期 | 目标 |
|---|
process-resources | resources:resources |
compile | compiler:compile |
process-test-resources | resources:testResources |
test-compile | compiler:testCompile |
test | surefire:test |
package | ejb:ejb or ejb3:ejb3 or jar:jar or par:par or rar:rar or war:war |
install | install:install |
deploy | deploy:deploy |
default生命周期绑定 - 封包格式ear
| 生命周期 | 目标 |
|---|
generate-resources | ear:generate-application-xml |
process-resources | resources:resources |
package | ear:ear |
install | install:install |
deploy | deploy:deploy |
default生命周期绑定 - 封包格式maven-plugin
| 生命周期 | 目标 |
|---|
generate-resources | plugin:descriptor |
process-resources | resources:resources |
compile | compiler:compile |
process-test-resources | resources:testResources |
test-compile | compiler:testCompile |
test | surefire:test |
package | jar:jar and plugin:addPluginArtifactMetadata |
install | install:install |
deploy | deploy:deploy |
default生命周期绑定 - 封包格式pom
| 生命周期 | 目标 |
|---|
package | site:attach-descriptor |
install | install:install |
deploy | deploy:deploy |
site生命周期绑定
| 生命周期 | 目标 |
|---|
site | site:site |
site-deploy | site:deploy |
参考
所有Maven生命周期是定义在maven-core模块的components.xml文件中，参考相关文件。
在Maven 2.x版本，默认生命周期的绑定被列入components.xml但在Maven 3.x版本中，他们是在一个单独的default-bindings.xml中所定义。
查看生命周期参考和默认生命周期下的插件绑定以直接从源代码中获得最新的文档。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
