maven学习之生命周期和插件

   Maven生命周期是对所有的构建过程进行抽象和统一。Maven从大量的项目和构件工具中学习和反思，总结出一套高度完善的、易扩展的生命周期。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有的构件步骤。Maven的生命周期是抽象的，意味着生命周期本身不做任何工作，具体工作都由插件来完成。该设计思想与设计模式中的模板方法—template method类似。模板模式的典型应用还有Spring JDBC读者要是感兴趣，可以自行查阅相关资料。 

       Maven有三套生命周期，分别是clean、default和site。clean生命周期主要是做项目清理的，default生命周期是用来项目构建的；site生命周期是用来建立项目站点的。三套生命周期是相互独立的。每个生命周期都有多个阶段（phase），例如clean生命周期就有pre-clean、clean、post-clean，用户与maven最直接的交互方式就是调用这些phase，例如调用pre-clean阶段、调用clean阶段（调用一套生命周期的某一阶段，那么其之前的阶段也会被执行，所以调用clean阶段实际上执行pre-clean、clean阶段)，调用post-clean则执行pre-clean、clean和post-clean。三套生命周期相互独立，所以调用三个周期的阶段不会对其他生命周期产生影响，例如调用default生命周期的阶段不会对clean生命周期产生影响。一个插件往往绑定一个或者多个阶段，例如maven-clean-plugin-2.5.jar插件的目标clean绑定的阶段为clean，执行pre-clean、clean阶段。在命令行输入的mvn命令可以是生命周期phase，例如mvn clean install，然后调用内置的插件来执行。也可以使用插件前缀:目标，例如 mvn compiler:compile、mvn dependency:list、mvn help:describe ….., 这里的compiler、dependency、help都是插件前缀； 下面说说内置绑定，首先maven自带了很多的插件，都是很多基本的插件，比如maven-clean-plugin、maven-compiler-plugin等等，这些都与一些生命周期进行了默认的绑定。三套生命周期与插件的默认绑定情况

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

pre-clean
clean	maven-clean-plugin：clean
post-clean

2、default生命周期的内置插件绑定关系及具体任务

生命周期阶段	插件目标	执行任务
validate
initialize
generate-sources
process-sources
generate-resources
process-resources	maven-resources-plugin:resources	复制主资源文件至输出目录
compile	maven-compiler-plugin:compile	编译主代码至主输出目录
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources	maven-resources-plugin:testResources	复制测试资源文件至测试输出目录
test-compile	maven-compiler-plugin:testCompile	编译测试代码至测试输出目录
test	maven-surefire-plugin:test	执行测试用例
prepare-package
package	maven-jar-plugin:jar	创建项目jar包
pre-integration-test
integration-test
post-integration-test
verify
install	maven-install-plugin:install	将项目输出构件安装到本地仓库
deploy	maven-deploy-plugin:deploy	将项目输出构件部署到远程仓库

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

生命周期阶段	插件目标
pre-site
site	maven-site-plugin：site
post-site
site-deploy	maven-site-plugin：deploy

       完成插件与生命周期的绑定后，用户还可以配置插件目标的参数，进一步调整插件目标所执行的任务。

在命令行通过-D配置插件目标参数，例如mvn clean install –Dmaven.skip.test=true;

在POM中配置插件的全局参数，这些参数从项目生成到发布一直都有效，例如

<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-compile阶段的maven-compiler-plugin：testCompile任务，都能够使用该配置，基于jdk1.5版本进行编译。

l  访问http://maven.apache.org/plugins/得到apache下的maven插件信息，如何使用这些插件，通过阅读该文档即可知道，有点需要知道的是，在描述插件信息的时候，不是每一个插件的参数都有表达式expression，有expression的代表可以通过命令行设置该插件参数。例如maven-surefire-plugin插件的skip参数的表达式为maven.skip.test，所以在命令行可以这么写：mvn clean install –Dmaven.skip.test=true，当然也可以在pom中配置skip参数达到同样的效果。不是每个插件的参数都有表达式值，所以有的插件的参数不可以通过命令行-D的方式来配置。

l  正常在mvn调用插件目标的写法应该是mvn groupId:artifactId:version:goal –D….

有了目标前缀也就是插件前缀goal prefix后就可以简写为mvn goal prefix:goal –D…

例如 mvn help:describe –Dplugin=install

为了方便用户使用和配置插件，maven不需要用户提供完整的插件坐标信息，就可以解析得到正确的插件。这是如何做到的？一步一步来…..

n  插件也是有坐标的，基于坐标存在maven仓库中的。

n  寻找插件时，先从本地仓库查找，如果有直接下载，使用。如果没有，则遍历远程插件仓库查找。

n  配置远程插件仓库如下

<pluginRepositories>

         <pluginRepository>

                   <id>….</id>

                   <name>….</name>

                   <url>….</url>

                   <layout>….</layout>

                   <snapshots>

                            <enabled>false</enabled>

                   </snapshots>

                  <releases>

                            <enabled>true</enabled>

                            <updatePolicy>never/daily/interval:X/always</updatePolicy>

                   </releases>

         <pluginRepository>

<pluginRepositories>

n  插件默认的groupId，如果所用的插件是maven官方的插件（org.apache.maven.plugins），那么在pom配置插件的时候，可以省略groupId,建议不要这么配，因为这样省略的代码仅仅一行，但是却让不熟悉maven的人产生疑惑。

n  解析插件的版本。同样是为了简化插件的配置和使用，在用户没有提供插件版本的情况下，maven会自动解析插件版本。如果所用的插件是maven的核心插件，如果没有指定版本，那么该插件的版本跟超级pom中的核心插件的版本一致，因为maven项目都会继承该超级pom。如果不是核心插件，并且没有指定插件版本的话，maven就去检查所有仓库的可用的版本，然后做出选择。Maven遍历本地仓库和远程插件仓库，合并仓库元数据（groupId/artifactId/maven-metadata.xml），会得到最新的release版本和latest版本，maven2会得到最新的latest版本的插件，但是有的时候该版本是非稳定的，所以maven3改进了解析机制，让得到的插件版本始终都是最新的release版本，即使这样，也还是会有问题，例如一个插件发布了一个最新的版本，但是这个插件的行为较之前的版本有了改变，这样也有可能导致项目构建失败，所以通常的做法是显示得声明插件的版本。

l  解析插件前缀

mvn命令支持使用插件前缀来简化插件的使用，那么maven是如何根据插件前缀得到插件坐标的。

n  插件前缀与groupId:artifactId是一一对应的，这种匹配关系存在仓库元数据，与之前提到的groupId/artifactId/maven-metadata.xml不同的是，这里的仓库元数据位于groupId/maven-metadata.xml，那这里的groupId是什么，默认的是org.apache.maven.plugins和org.codehaus.mojo这两个groupId，也可以通过配置setting.xml文件让maven也检查其他groupId的仓库元数据

<settings>

         ….

         <pluginGroups>

                   <pluginGroup>…..</pluginGroup>

         </pluginGroups

….

                   </settings>

n  仓库元数据的格式为

<metadata>

         <plugins>

                   <plugin>

                            <name>….</name>

                            <prefix>….</prefix>

                            <artifactId>….</artifactId>

                   </plugin>

                   …….

         <plugins>

</metadata>

根据根据插件前缀解析插件坐标时，首先根据groupId找到仓库元数据，合并仓库元数据后，查新prefix等于所给插件前缀的artifactId，这样就得到了该插件的groupId、artifactId，再根据前面提到的解析插件版本步骤解析该插件的版本。