Maven的生命周期就是为了对所有的构建过程进行抽象和统一。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。也就是说，几乎所有项目的构建，都能映射到这样一个生命周期上。
Maven生命周期：
注意：执行后面的命令时，前面的命令自动得到执行。
Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，在Maven的设计中，实际的任务（如编译源代码)都交由插件来完成。
生命周期中的每个构建步骤都可以绑定一个或者多个插件行为，而且Maven为大多数构建步骤编写并绑定了默认插件。例如，针对编译的插件有maven-compiler-plugin,针对测试的插件有maven-surefire-plugin等)虽然在大多数时间里，用户几乎都不会觉察到插件的存在，但实际上编译是由maven-compiler–plugin完成的，而测试是由maven-surefire-plugin完成的。
三套生命周期
初学者往往会以为Maven的生命周期是一个整体，其实不然，Maven拥有三套相互独立的生命周期，它们分别为clean、default和site。clean生命周期的目的是清理项目，default生命周期的目的是构建项目，而site生命周期的目的是建立项目站点。
每个生命周期包含一些阶段(phase),这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，和Maven最直接的交互方式就是调用这些生命周期阶段。以clean生命周期为例，它包含的阶段有pre-clean、clean和post-clean。当用户调用pre-clean的时候，只有pre-clean阶段得以执行；当用户调用clean的时候，pre-clean和clean阶段会得以顺序执行；当用户调用post-clean的时候，pre-clean、clean和post-clean会得以顺序执行。
较之于生命周期中阶段的前后依赖关系，三套生命周期本身是相互独立的，用户可以仅仅调用clean生命周期的某个阶段，或者仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响。例如，当用户调用clean生命周期的clean阶段的时候，不会触发default生命周期的任何阶段，反之亦然，当用户调用default生命周期的compile阶段的时候，也不会触发clean生命周期的任何阶段。
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，会自动进行clean+compile
-
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 将生成的项目站点发布到服务器上
命令行与生命周期
从命令行执行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阶段、default生命周期的deploy阶段，以及site生命周期的site-deploy阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段，default生命周期的所有阶段，以及site生命周期的所有阶段。该命令结合了Maven所有三个生命周期，且deploy为default生命周期的最后一个阶段，site-deploy为site生命周期的最后一个阶段。
插件目标
Maven的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构件形式存在。
对于插件本身，为了能够复用代码，它往往能够完成多个任务。例如maven-dependency-plugin,它能够基于项目依赖做很多事情。它能够分析项目依赖，帮助找出潜在的无用依赖；它能够列出项目的依赖树，帮助分析依赖来源；它能够列出项目所有已解析的依赖，等等。为每个这样的功能编写一个独立的插件显然是不可取的，因为这些任务背后有很多可以复用的代码，因此，这些功能聚集在一个插件里，每个功能就是一个插件目标。
maven-dependency-plugin有十多个目标，每个目标对应了一个功能，上述提到的几个功能分别对应的插件目标为dependency:analyze、dependency:tree和dependency:list。这是一种通用的写法，冒号前面是插件前缀，冒号后面是该插件的目标。
插件绑定
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。例如项目编译这一任务，它对应了default生命周期的compile这一阶段，而maven–compiler-plugin这一插件的compile目标能够完成该任务。因此，将它们绑定，就能实现项目编译的目的，如下图：
内置绑定
为了能让用户几乎不用任何配置就能构建Maven项目，Maven核心已为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务。
clean生命周期仅有pre-clean、clean和post-clean三个阶段，其中的clean与maven-clean-plugin:clean绑定。maven-clean-plugin仅有clean这一个目标，其作用就是删除项目的输出目录。
site生命周期有pre-site、site、post-site和site-deploy四个阶段，其中，site和maven-site-plugin:site相互绑定，site-deploy和maven-site-plugin:depoy相互绑定。maven-site-plugin有很多目标，其中，site目标用来生成项目站点，deploy目标用来将项目站点部署到远程服务器上。
clean生命周期阶段与插件目标的绑定关系：
| 生命周期阶段 | 插件目标 |
|---|---|
| pre-clean | maven-clean-plugin：clean |
| clean | maven-clean-plugin：clean |
| post-clean | maven-clean-plugin：clean |
site生命周期阶段与插件目标的绑定关系：
| 生命周期阶段 | 插件目标 |
|---|---|
| pre-site | maven-site-plugin：site |
| site | maven-site-plugin：site |
| post-site | maven-site-plugin：site |
| site-deploy | maven-site-plugin：deploy |
由于项目的打包类型(jar、war等)会影响构建的具体过程，因此，default生命周期的阶段与插件目标的绑定关系由项目打包类型所决定，打包类型是通过POM中的packaging元素定义的。最常见、最重要的打包类型是jar,它也是默认的打包类型。基于该打包类型的项目，其default生命周期的内置插件绑定关系及具体任务如下表所示：
default生命周期的内置插件绑定关系及具体任务（打包类型：jar）：
| 生命周期阶段 | 插件目标 | 执行任务 |
|---|---|---|
| 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生命周期还有很多其他阶段，默认它们没有绑定任何插件，因此也没有任何实际行为。
除了默认的打包类型jar之外，常见的打包类型还有war、pom、maven–plugin、ear等。
自定义绑定
除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上。
一个常见的例子是创建项目的源码jar包，内置的插件绑定关系中并没有涉及这一任务，因此需要用户自行配置。maven-source-plugin可以帮助我们完成该任务，它的jar-no-fork目标能够将项目的主代码打包成jar文件，可以将其绑定到default生命周期的verify阶段上，在执行完集成测试后和安装构件之前创建源码j包。具体配置如下：
<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元素下的plugins子元素中声明插件的使用，该例中用到的是maven-scurce-plugin,其groupld为org.apache.maven.plugins，这也是Maven官方插件的groupId，紧接着artifactId为maven-source-plugin,version为2.1.1。
上述配置中，除了基本的插件坐标声明外，还有插件执行配置，executions下每个execution子元素可以用来配置执行一个任务。该例中配置了一个id为attach-.sources的任务，通过phrase配置，将其绑定到verify生命周期阶段上，再通过goals配置指定要执行的插件目标。至此，自定义插件绑定完成。
有时候，即使不通过phase元素配置生命周期阶段，插件目标也能够绑定到生命周期中去。出现这种现象的原因是：有很多插件的目标在编写时已经定义了默认绑定阶段。可以使用maven-help-plugin查看插件详细信息，了解插件目标的默认绑定阶段。运行命令如下
mvn help:describe-Dplugin=org.apache.maven.plugins:maven-source-plugin:2.1.1-Ddetail
在输出结果中Bound to phase这一项，它就表示该目标默认绑定的生命周期阶段。
当多个插件目标绑定到同一个阶段的时候，这些插件声明的先后顺序决定了目标的执行顺序。
插件配置
完成插件和生命周期的绑定之后，还可以配置插件目标的参数，进一步调整插件目标所执行的任务。几乎所有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</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任务，就都能够使用该配置，基于Java1.5版本进行编译。
POM中插件任务配置
除了为插件配置全局的参数，还可以为某个插件任务配置特定的参数
<build>
<plugins>
<plugin>
<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>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>
在上述代码片段中，首先，maven-antrun-plugin:run与validate阶段绑定，从而构成一个id为ant-validate的任务。插件全局配置中的configuration元素位于plugin元素下，而这里的configuration元素则位于execution元素下，表示这是特定任务的配置，而非插件整体的配置。这个ant-validate任务配置了一个echo Ant任务，向命令行输出一段文字，表示该任务是绑定到validate阶段的。第二个任务的id为ant-verify,它绑定到了verify阶段，同样它也输出一段文字到命令行，告诉该任务绑定到了verify阶段。
获取插件信息
在线插件信息
详细的插件列表访问地址：http://maven.apache.org/plugins/index.html。单击某个插件的链接便可以得到插件进一步的信息。
官方插件下载地址：https://repo1.maven.org/maven2/org/apache/maven/plugins/
使用maven-help-plugin描述插件
借助maven-help-plugin来获取插件的详细信息。例如，可以运行如下命令来获取
maven-compiler-plugin 2.1版本的信息：
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin:2.1。
这里执行的是maven-help-plugin的describe目标，在参数plugin中输入需要描述插件的groupId、artifactId和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命令帮助,输出结果中显示了mvn命令的基本用法，options表示可用的选项，mvn命令有20多个选项。
可以通过mvn命令激活生命周期阶段，从而执行那些绑定在生命周期阶段上的插件目标。但Maven还支持直接从命令行调用插件日标。
插件解析机制
与依赖构件一样，插件构件同样基于坐标存储在Maven仓库中。在需要的时候，Maven会从本地仓库寻找插件，如果不存在，则从远程仓库查找。找到插件之后，再下载到本地仓库使用。
不同于repositories及其repository子元素，插件的远程仓库使用pluginRepositories和pluginRepository配置。例如，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标签不同之外，其余所有子元素表达的含义与依赖的远程仓库配置完全一样。甚至，这个默认插件仓库的地址就是中央仓库，它关闭了对SNAPSHOT的支持，以防止引入SNAPSHOT版本的插件而导致不稳定的构建。
一般来说，中央仓库所包含的插件完全能够满足我们的需要，因此也不需要配置其他的插件仓库。只有在很少的情况下，项目使用的插件无法在中央仓库找到，或者自己编写了插件，这个时候可以参考上述的配置，在POM或者settings…xml中加入其他的插件仓库配置。
插件的默认groupld
在POM中配置插件的时候，如果该插件是Maven的官方插件（即如果其groupld为
org.apache.maven.plugins),就可以省略groupld配置。
<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会自动解析插件版本。
Maven在超级POM中为所有核心插件设定了版本，超级POM是所有Maven项目的父POM,所有项目都继承这个超级POM的配置，因此，即使用户不加任何配置，Maven使用核心插件的时候，它们的版本就已经确定了。这些插件包括maven-clean-plugin、maven-compiler-plugin、maven-surefire-plugin等。
如果用户使用某个插件时没有设定版本，而这个插件又不属于核心插件的范畴，Maven就会去检查所有仓库中可用的版本，然后做出选择。
Maven遍历本地仓库和所有远程插件仓库，将该路径下的仓库元数据归并后，就能计算出latest和release的值。latest表示所有仓库中该构件的最新版本，而release表示最新的非快照版本。在Maven2中，插件的版本会被解析至latest。也就是说，当用户使用某个非核心插件且没有声明版本的时候，Maven会将版本解析为所有可用仓库中的最新版本，而这个版本也可能是快照版。
当插件的版本为快照版本时，就会出现潜在的问题。Maven会基于更新策略，检查并使用快照的更新。某个插件可能昨天还用得好好的，今天就出错了，其原因就是这个快照版本的插件发生了变化。为了防止这类问题，Maven3调整了解析机制，当插件没有声明版本的时候，不再解析至latest,而是使用release。这样就可以避免由于快照频繁更新而导致的插件行为不稳定。
解析插件前缀
插件前缀与groupld:artifactld是一一对应的，这种匹配关系存储在仓库元数据中。这里的仓库元数据为groupld/maven-metadata.xml。Maven在解析插件仓库元数据的时候，这里的groupld会默认使用org.apache.maven.plugins和org.codehaus…mojo两个groupld。
当Maven解析到例如dependency:tree这样的命令后，它首先基于默认的groupld归并所有插件仓库的元数据org/apache/maven/plugins/maven-metadata.xml；其次检查归并后的元数据，找到对应的artifactld为maven-dependency-plugin；然后结合当前元数据的groupldorg.apache.maven.plugins;最后使用上述解析插件版本的方法解析得到version,这时就得到了完整的插件坐标。
扫一扫
332
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
