何为生命周期：
Maven的生命周期就是为了对全部的构建过程进行抽象和统一。Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完好的、易扩展的生命周期。这个生命周期包括了项目的清理、初始化、编译、測试、打包、集成測试、验证、部署和网站生成等差点儿全部构建步骤。也就是说，差点儿全部项目的构建，都能映射到这样一个生命周期上。
Maven的生命周期是抽象的，这意味着生命周期本身不做不论什么实际的工作，在Maven的设计中。实际的任务(如编译源码)都交由插件来完毕。这样的思想与设计模式中的模板方法(Template Method)很相似。每一个构建步骤都能够绑定一个或者多个插件行为。而Maven为大多数构建步骤编写并绑定了默认插件。
当用户有特殊须要的时候，也能够配置插件定制构建行为。甚至自己编写插件。
生命周期具体解释：
三套生命周期：
Maven拥有三套互相独立的生命周期，它们各自是clean、default和site。clean生命周期的目的是清理项目，default生命周期的目的是构建项目，而site生命周期的目的是建立项目网站。
每一个生命周期包括一些阶段，这些阶段是有顺序的。而且后面的阶段依赖于前面的阶段。用户和Maven最直接的交互方式就是调用这些生命周期阶段。较之于生命周期阶段的前后依赖关系。三套生命周期本身是相互独立的。
Clean生命周期：
clean生命周期的目的是清理项目，它包括三个阶段:
- pre-clean：运行一些清理前须要完毕的工作
- clean：清理上一次构建生成的文件
- post-clean：运行一些清理后须要完毕的工作
- validate
- initialize
- generate-source
- process-sources：处理项目主资源文件。
一般来说。是对src/main/resource文件夹的内容进行变量替换等工作后，拷贝到项目输出的主classpath文件夹中。
- generate-resources
- process-resources
- compile：编译项目的源码。一般来说，是编译src/main/java文件夹下的Java文件至项目输出的主classpath文件夹中
- process-classes
- generate-test-sources
- process-test-sources：处理项目測试资源文件。一般来说，是对src/test/resource文件夹的内容进行变量替换等工作后，拷贝到项目输出的主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：将生成的项目网站公布到server上
从命令行运行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阶段。default生命周期的deploy阶段。以及site生命周期的site-deploy周期。
实际运行的阶段为clean生命周期的pre-clean、clean阶段，default生命周期的全部阶段，以及site生命周期的全部阶段。该命令结合了Maven全部三个生命周期，且deploy为default生命周期的最后一个阶段，site-deploy为site生命周期的最后一个阶段。
插件目标：
对于插件本身，为了可以复用代码，它往往可以完毕多个任务。比如maven-dependency-plugin，它可以基于项目依赖做非常多事情。
它可以分析项目依赖。帮助找出潜在的无用依赖；它可以列出项目的依赖树。帮助分析依赖来源；它可以列出项目全部已解析的依赖，等等。
为每一个这种功能编写一个独立的插件显然是不可取的，由于这些任务背后有非常多可以复用的代码。因此。这些功能聚集在一个插件里。每一个功能就是一个插件目标。
maven-dependency-plugin有十多个目标，每一个目标相应了一个功能。上诉提到的几个功能分别相应的插件目标为dependency:analyze、dependency:tree和dependency:list。
插件绑定：
Maven的生命周期与插件相互绑定。用以完毕实际的构建任务。详细而言，是生命周期的阶段与插件的目标相互绑定。以完毕某个详细的构建任务。比如项目编译这一任务，它相应了default生命周期的compile这一阶段，而maven-compile-plugin这一插件的compile目标能完毕该任务。
内置绑定：
Maven为一些核心的生命周期绑定了非常多插件的目标，当用户通过命令行调用生命周期阶段的时候。相应的插件目标就会运行相应的任务。
clean生命周期阶段与插件目标的绑定关系：
| 生命周期阶段 | 插件目标 |
| pre-clean clean post-clean |
maven-clean-plugin:clean |
site生命周期阶段与插件目标的绑定关系：
| 生命周期阶段 | 插件目标 |
| pre-site site post-site site-deploy |
maven-site-plugin:site maven-site-plugin:deploy |
相对于clean和site生命周期来说。default生命周期与插件目标的绑定关系就显得复杂一些。因为项目的打包类型会影响构建的详细过程，因此，default生命周期的阶段与插件目标的绑定关系由项目打包类型所决定，打包类型是通过packaging元素定义的。最常见、最重要的打包类型是jar。它也是默认的打包类型。
基于该打包类型的项目。其default生命周期的内置插件绑定关系及详细任务例如以下：
| 生命周期阶段 | 插件目标 |
| process-resources compile process-test-resources test-compile test package install deploy |
maven-resources-plugin:resources maven-compiler-plugin:compile maven-resources-plugin:testResources
maven-compiler-plugin:testCompile
maven-surefire-plugin:test
maven-jar-plugin:jar
maven-intall-plugin:install
maven-deploy-plugin:deploy
|
除了默认的打包类型jar之外，常见的打包类型还有war、pom、maven-plugin、ear等。
自己定义绑定：
除了内置绑定以外。用户还可以自己选择将某个插件目标绑定到生命周期的某个阶段上。
一个常见的样例是创建项目的源代码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> 在插件运行配置中，executions下每一个execution子元素能够用来配置运行一个任务。该例中配置了一个id为attach-sources的任务，通过phase配置，将其绑定到verify生命周期阶段上，再通过goals配置指定要运行的插件目标。
有时候，即使不通过phase元素配置生命周期阶段，插件目标也可以绑定到生命周期中去。出现这样的现象的原因是：有非常多插件的目标在编写时已经定义了默认绑定阶段。可以使用maven-help-plugin查看插件具体信息，了解插件目标的默认绑定阶段。执行命令例如以下：
$mvn help:describe -Dplugin = org.apache.maven.plugins:maven -source-plugin:2.1.1 -Ddetail
当插件目标被绑定到不同的生命周期阶段的时候，其运行顺序会由生命周期阶段的先后顺序决定。当多个插件目标绑定到同一个阶段的时候。这些插件生命的先后顺序决定了目标的运行顺序。
插件配置：
用户能够配置插件目标的參数，进一步调整插件目标所运行的任务，以满足项目的需求。
命令行插件配置：
非常多插件目标的參数都支持从命令行配置。用户能够在Maven命令中使用-D參数，并伴随一个參数键=參数值的形式，来配置插件目标的參数。
比如，maven-surefire-plugin提供了一个maven.test.skip參数。当其值为true的时候，就会跳过执行測试。
于是，在执行命令的时候。加上例如以下-D參数就能跳过測试：
$mvn install -Dmaven.test.skip=true
POM中插件全局配置：
并非全部的插件參数都适合从命令行配置。有些參数的值从项目创建到项目公布都不会改变，或者说非常少改变，对于这样的情况，在POM文件里一次性配置就显然比反复在命令行输入要方便。
比如。我们通常须要配置maven-compiler-plugin告诉它编译Java 1.5版本号的源文件，生成与JVM 1.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> POM中插件任务配置：
除了为插件配置全局的參数，用户还能够为某个任务配置特定的參数。
以maven-antrun-plugin为例，它有一个目标run。能够用来在Maven中调用Ant任务。用户将maven-antrun-plugin:run绑定到多个生命周期阶段上，再加上不同的配置，就能够让Maven在不同的生命周期运行不同的任务，代码例如以下：
<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> 插件全局配置中的configuration元素位于plugin元素以下，而这里的configration元素则位于execution元素下，表示这是特定任务的配置，而非插件总体的配置。这个ant-validate任务配置了一个echo Ant任务，向命令行输出一段文字，表示该任务是绑定到validate阶段的。第二个任务的id为ant-verify。它绑定到了verify阶段。相同它也输出一段文字到命令行，告诉该任务绑定到了verify阶段。
获取插件信息：
在线插件信息：
因为Maven本身是属于apache软件基金会的，因此它有非常多官方的插件。它们都具有非常好的稳定性。具体的列表能够在这个地址得到：http://maven.apache.org/plugins/index.html
，单击某个插件的链接便能够得到进一步的信息。
以maven-surefire-plugin为例。訪问http://maven.apache.org/plugins/maven-surefire-plugin/能够看到该插件的简要介绍、包括的目标、使用介绍、FAQ以及非常多实例。一般来说，通过阅读插件文档中的使用介绍和实例，就应该能够在自己的项目中非常好的使用该插件。但当我们想了解非常细节的目标參数时。就须要进一步訪问该插件每一个目标的文档。以maven-surefire-plugin为例，能够通过在命令行传入maven.test.skip參数来跳过測试运行。而运行測试的插件目标是surefire:test，訪问其文档http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html,能够找到目标參数skip。
文档详解了该參数的作用、类型等信息。基于该信息，用户能够在POM中配置maven-surefire-plugin的skip參数为true来跳过測试。尽管在命令行传入的參数为maven.test.skip，可是在POM中配置的參数为skip。这两者对于插件目标的作用是一样的，但从命令行传入的參数确实不同于该插件目标的參数名称。命令行參数是由该插件參数的表达式(Expression)决定的。
从上图中能够看到，surefire:test skip參数的表达式为${maven.test.skip}。它表示能够在命令行以-Dmaven.test.skip=true的方式配置该目标。
并非全部插件目标參数都有表达式。也就是说，一些插件目标參数仅仅能在POM中配置。
使用maven-help-plugin描写叙述插件：
除了訪问在线的插件文档之外，还能够借助maven-help-plugin来获取插件的具体信息。能够执行例如以下的命令来获取maven-compiler-plugin 2.1版本号的信息：
$mvn help:describe -Dplugin = org.apache.maven.plugins:maven-compiler-plugin:2.1
能够看到例如以下输出：
.png)
这里值得一提的是目标前缀(goal prefix)。其作用是方便在命令行直接执行插件。maven-compiler-plugin的目标前缀是compiler。
在描写叙述插件的时候。还能够省去版本号信息，让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，它们各自是指插件目标和生命周期阶段。maven支持从命令行调用插件目标是由于有些任务不适合绑定在生命周期上，比如：maven-help-plugin:descirbe，我们不须要在构建项目的时候去描写叙述插件信息。又如maven-denpendency-plugin:tree。我们也不须要在构建项目的时候去显示依赖树。因此这些插件目标应该通过例如以下方式使用：
$mvn help:describe-Dplugin=compiler
$mvn denpendency:tree
这里是通过插件的前缀来找到目标插件的。
插件解析机制：
插件仓库：
与依赖构件一样。插件构件相同基于坐标储存在Maven仓库中。在须要的时候，Maven会从本地仓库寻找插件，假设不存在，则从远程插件仓库查找。找到插件之后，再下载到本地仓库使用。
Maven差别对待依赖的远程仓库与插件的远程仓库。
不同于repositories及其respository子元素，插件的远程仓库使用pluginRepositories和pluginRepository配置。比如，Maven内置了例如以下的插件远程仓库配置。
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository
<url>http://repo1.maven.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
一般来说，中央仓库所包括的插件全然可以满足我们的须要，因此也不须要配置其它的插件仓库。
仅仅有在非常少的情况下，项目使用的插件无法在中央仓库找到，或者自己编写了插件。这个时候可以參考上述的配置。在POM或者settings.xml中增加其它的插件仓库配置。
插件的默认groupId:
在POM中配置插件的时候。假设该插件是Maven的官方插件(即假设其groupId为org.apache.maven.plugins)，就能够省略groupId配置。可是不推荐使用这样的做法，可能会使一些不熟悉Maven的人对这样的行为费解。
解析插件版本号：
相同是为了简化插件的配置和使用，在用户没有提供插件版本号的情况下，Maven会自己主动解析插件版本号。
首先。Maven在超级POM中为全部核心插件设定了版本号，超级POM是全部Maven项目的父POM，全部项目都继承了这个超级POM的配置。因此，即使用户不加不论什么配置，Maven使用核心插件的时候。它们的版本号就已经确定了。这些插件包含maven-clean-plugin、maven-compiler-plugin、maven-surefire-plugin等。
假设用户使用某个插件时没有设定版本号。而这个插件又不属于核心插件的范畴，Maven就会去检查全部仓库中可用的版本号，然后做出选择。
Maven会遍历本地仓库和全部远程插件仓库，将该路径下的仓库元数据归并后，就能计算出latest和release的值。latest表示全部仓库中该构件的最新版本号。而release表示最新的非快照版本号。在Maven3中，会使用release版本号。
依赖Maven解析插件事实上是不推荐的做法，即使Maven 3将版本号解析到最新的非快照版，也还是会有潜在的不稳定性。比如，可能某个插件公布了一个新的版本号。而这个版本号的行为与之前的版本号发生了改变，这样的变化就可能会导致项目构建失败。因此，使用插件的时候，应该一直显式地设定版本号，这也解释了Maven为什么要在超级POM中为核心插件设定版本号。