Maven学习笔记(六)：生命周期与插件

何为生命周期：

     Maven的生命周期就是为了对所有的构建过程进行抽象和统一。Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完善的、易扩展的生命周期。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。也就是说，几乎所有项目的构建，都能映射到这样一个生命周期上。

     Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，在Maven的设计中，实际的任务(如编译源代码)都交由插件来完成。这种思想与设计模式中的模板方法(Template Method)非常相似。每个构建步骤都可以绑定一个或者多个插件行为，而Maven为大多数构建步骤编写并绑定了默认插件。当用户有特殊需要的时候，也可以配置插件定制构建行为，甚至自己编写插件。

生命周期详解：

三套生命周期：

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

     每个生命周期包含一些阶段，这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段。较之于生命周期阶段的前后依赖关系，三套生命周期本身是相互独立的。

Clean生命周期：

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

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

default生命周期：     

• 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：将生成的项目站点发布到服务器上

命令行与生命周期：

     从命令行执行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包。

     
          
               org.apache.maven.plugins               
               maven-source-plugin
               2.1.1
               
                    
                         attach-sources
                         verify
                         
                              jar-no-fork
                         
                    
               
          
     
     

     在插件执行配置中，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兼容的字节码文件，代码如下：

     
          
               org.apache.maven.plugins               
               maven-compiler-plugin
               2.1
               
                    1.5
                    1.5
               
          
     
  

POM中插件任务配置：

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

     
          
               org.apache.maven.plugins               
               maven-antrun-plugin
               1.3
               
                    
                         ant-validate
                         validate
                         
                              run
                         
                         
                              
                                   I'm bound to validate phase.
                              
                         
                    
                   
                         ant-verify
                         verify
                         
                              run
                         
                         
                              
                                   I'm bound to verify phase.
                              
                         
                    
               
          
     
    

     插件全局配置中的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

     可以看到如下输出：

     这里值得一提的是目标前缀(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] [] []

     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内置了如下的插件远程仓库配置。

            
                
                    central
                    Maven Plugin Repository
                    http://repo1.maven.org/maven2
                    default
                    
                        false
                    
                    
                        never
                    
                     

     一般来说，中央仓库所包含的插件完全能够满足我们的需要，因此也不需要配置其他的插件仓库。只有在很少的情况下，项目使用的插件无法在中央仓库找到，或者自己编写了插件，这个时候可以参考上述的配置，在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中为核心插件设定版本。