Maven生命周期和插件
Posted shi_zi_183
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Maven生命周期和插件相关的知识，希望对你有一定的参考价值。
Maven生命周期和插件
除了坐标、依赖以及仓库之外，Maven另外两个核心概念是生命周期和插件。在有关Maven的日常使用中，命令行的输入往往就对应了生命周期，如mvn package就表示执行默认生命周期阶段package。Maven的生命周期是抽象的，其实际行为都由插件来完成，如package阶段的认为可能就会由maven-jar-plugin完成。
何为生命周期
在Maven出现之前，项目构件的生命周期就已经存在，软件开发人员每天都在对项目进行清理、编译、测试及部署。虽然大家都不停地做构建工作，但公司和公司间、项目和项目间，往往使用不同地方式做类似地工作。有的项目以手工的方式在执行编译测试，有的项目写了自动化脚本执行编译测试。可以想象的是，虽然各种手工方式十分类似，但不可能完全一样；同样地，对于自动化脚本，大家也是各写各的，能满足自身需求即可，换个项目就需要重新来过。
Maven的生命周期就是为了对所有的构建过程进行抽象和统一。Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完善的、易拓展的生命周期。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。也就是说，几乎所有项目的构建，都能映射到这样一个生命周期上。
Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，在Maven的设计中，实际的任务都交由插件来完成。这种思想与设计模式中的模板方法非常相似。模板方法模式在父类中定义算法的整体结构，子类可以通过实现或重写父类的方法来控制实际的行为，这样既保证了算法有足够的可拓展性，又能够严格控制算法的整体结构。
生命周期详解
三套生命周期
Maven拥有三套相互独立的生命周期，它们分别为clean、default和site。clean生命周期的目的是清理项目，以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生命周期
- pre-clean 执行一些清理前需要完成的工作
- clean 清理上一次构建生成的文件
- post-clean 执行一些清理后需要完成的工作
default生命周期
- validate
- initialize
- generate-sources
- proess-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/resources目录的内容进行变量替换等工作后，复制到项目输出的测试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 生成项目站点文档
- site-deploy 将生成的项目站点发布到服务器上
命令行与生命周期
从命令行执行Maven任务的最主要方式就是调用Maven的生命周期阶段。需要注意的是，各个生命周期是相互独立的，而一个生命周期的阶段是有前后依赖关系的。
- mvn clean：该命令调用clean生命周期的clean阶段。实际执行的阶段为clean生命周期的pre-clean和clean阶段。
- mvn test：该命令调用default生命周期的test阶段。实际执行的阶段为default生命周期的validate、initialze等，直到test的所有阶段。这也解释了为什么在执行测试的时候，项目的代码能够自动得以编译。
- mvn clean install：该命令用clean阶段和default生命周期的install阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段、以及default生命阶段的从validate至install的所有阶段。该命令结合了两个生命周期，在执行真正的项目构建之前清理项目是一个很好的实践。
- mvn clean deploy site-deploy：该命令调用clean生命周期的clean阶段、default生命周期的deploy阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段，default生命周期的所有阶段，以及site生命周期的所有阶段。该命令结合了Maven所有三个生命周期，且deploy为default生命周期的最后一个阶段，site-deploy为site生命周期的最后一个阶段。
插件目标
Maven的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构建形式存在，因此，Maven核心的分发包只有不到3MB的大小，Maven会在需要的时候下载并使用插件。
对于插件本身，为了能够复用代码，它往往能够完成多个任务。
插件绑定
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。
内置绑定
为了能让用户几乎不用任何配置就能构建Maven项目，Maven在核心为一些主要的生命周期阶段绑定了很多绑定的目标，当用户通过命令行调用生命周期阶段的实践，对应的插件目标就会执行相应的任务。
clean生命周期仅有pre-clean、clean和post-clean三个阶段，其中的clean与maven-clean-plugin:clean绑定。maven-clean-plugin仅有clean这一个目标，其作用就是删除项目的输出目录。
| 生命周期阶段 | 插件目标 |
|---|---|
| pre-clean | |
| clean | maven-clean-plugin:clean |
| post-clean | |
| pre-site | |
| site | maven-site-plugin:site |
| post-site | |
| site-deploy | maven-site-plugin:deploy |
相对于clean和site生命周期来说，default生命周期与插件目标的绑定关系就显得复杂一些。
由于项目的打包类型会影响构建的具体过程，因此default生命周期的阶段与插件目标的绑定关系由项目打包类型所决定，打包类型是通过POM中的packaging元素定义的。
最常见、最重要的打包类型是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生命周期还有很多其他阶段，默认它们没有绑定任何插件，因此也没有任何实际行为。
mvn clean install
自定义绑定
除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上，这种自定义绑定方式能让Maven项目在构建过程中执行更多更富特色的任务。
一个常见的例子是创建源码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>
在POM的build元素下的plugin子元素中声明插件的使用，改隶中用到的是maven-source-plugin，其groupId为org.apache.maven.plugins，这也是Maven官方插件的groupId，紧接着artifactId为maven-source-plugin，version为2.1.1。
上述配置中，除了基本的插件坐标声明外，还有插件执行配置，executions下每个execution子元素可以用来配置执行一个任务。该例中配置了一个id为attach-sources的任务通过phrase配置，将其绑定到verify声明周期阶段上，再通过goals配置指定要执行的插件目标。
mvn verify
有时候，即使不通过phase元素配置声明周期阶段，插件也能够绑定到声明周期中去。去掉phase一行，再次执行
mvn verify
仍然可以看到maven-source-plugin:jar-no-fork得以执行。出现这种现象的原因是：有很多插件的目标再编写时已经定义了默认绑定阶段。
可以使用
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:2.1.1 -Ddetail
查看插件详细信息
该输出包含了一段关于jar-no-fork目标的描述，这里关系的是Bound to phase这一项，它表示该目标默认绑定的生命周期阶段，这里是package。如果不指定phase参数，该目标就会被绑定到package阶段。
当多个插件目标绑定到同一个阶段的时候，这些插件声明的先后顺序决定了目标的执行顺序。
插件配置
几乎所有Maven插件的目标都有一些可配置的参数，用户可以通过命令行和POM配置等这些参数。
命令行插件配置
很多插件目标的参数都支持从命令行配置，用户可以在Maven命令中使用-D参数，并伴随一个参数键=参数值的形式，来配置插件目标的参数。
例如
mvn install -Dmaven.test.skip=true
参数-D是Java自带的，其功能是通过命令行设置一个Java系统参数，Maven简单地重用了该参数，在准备插件地时候检查系统属性，便实现了插件参数的配置。
POM中插件全局配置
并不是所有的插件参数都适合从命令行配置，有些参数的值从项目创建到项目发布都不会改变，或者说很少改变，对于这种情况，在POM文件中一次性配置就显然比重复在命令行输入要方便。
用户可以在声明插件的时候，对此插件进行一个全局的配置。所有该基于该插件目标的任务，都会使用这些配置。
<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>
这样，不管绑定到compile阶段的maven-compiler-plugin:compile任务，还是绑定到test-compiler阶段的maven-compiler-plugin:testCompiler任务，就都能够使用该配置，基于java1.5版本进行编译。
POM中插件任务配置
除了为插件配置全局的参数，用户还可以为某个插件任务配置特定的参数。
<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 bount 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 bount to verify phase.</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
插件解析机制
插件仓库
与依赖构件一样，插件构件同样基于坐标存储在Maven仓库中。在需要的时候，Maven会从本地仓库寻找插件，如果不存在，则从远程插件仓库查找。找到插件之后，再下载到本地仓库使用。
注：Maven会区别对待依赖的远程仓库与插件的远程仓库。当Maven需要的依赖再本地仓库不存在时，他会去配置的远程仓库查找，可是当Maven需要的插件在本地仓库不存在时，它就不会去这些远程仓库查找。
插件的默认groupId
在POM中配置插件的时候，如果该插件是Maven官方插件，就可以省略groupId配置。
解析插件版本
在POM中配置插件的时候，如果省略版本，Maven会去仓库查找release，但一直变化的版本可能会导致项目构建失败，应该一直显式地设定版本。
解析插件前缀
Maven在解析插件仓库元数据的时候，会默认使用org.apache.maven.plugins和org.codehaus.mojo两个groupId。也可以通过配置settings.xml让Maven检查其他groupId上的插件仓库元数据：
<pluginGroups>
<pluginGroup>com.your.plugins</pluginGroup>
</pluginGroups>
基于该配置，Maven就不仅仅检查org/apache/maven/plugins/maven-metadata.xml和org/codehaus/mojo/maven-metadata.xml，还会检查com/your/plugins/maven-metadata.xml
以上是关于Maven生命周期和插件的主要内容，如果未能解决你的问题，请参考以下文章