Maven plugin中的lifecycle、phase、goal、mojo概念及作用的理解

Maven

 

Maven有一个十分完善的生命周期模型(lifecycle),它有三套相互独立的生命周期，请注意这里说的是三套，而且相互独立，请别将Maven的生命周期看成一个整体哦，三个生命周期是独立线性执行的！分别是： 
1. Clean Lifecycle 在进行真正的构建之前进行一些清理工作。 
2. Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。 
3. Site Lifecycle 生成项目报告，站点，发布站点。 

每个生命周期包含一些阶段(phase)，这些阶段(phase)是有顺序的，每个阶段蕴含一个或多个目标(goal)，并且后面的阶段依赖于前面的阶段，我们和Maven最直接的交互方式就是调用这些生命周期阶段。 

较之于生命周期阶段的前后依赖关系，三套生命周期本身是相互独立的，用户可以仅仅调用clean生命周期的某个阶段，或者仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响。例如，当用户调用clean生命周期的clean阶段的时候，不会触发default生命周期的任何阶段。 

其中deault是最重要的生命周期，拥有validate 、compile 、test 、package 、integration、verify、install、deploy等等阶段 

1. clean

用于清除之前构建生成的所有文件其中具体为清楚了Target目录中的所有文件，包括该目录,i.e：删除了install生成的所有文件

pre-clean  执行一些需要在clean之前完成的工作

clean  移除所有上一次构建生成的文件

post-clean  执行一些需要在clean之后立刻完成的工作

2.validate

用于验证工程是否真确，所需信息是否完整

generate-sources

process-sources

generate-resources

process-resources  复制并处理资源文件，至目标目录，准备打包

3.compile

编译项目的源代码，主要是java文件

一般是编译scr/main/java或是scr/test/java里面的文件

process-classes    源码编译后的后期处理，比如java字节码的增强（优化？）

generate-test-sources

process-test-sources

generate-test-resources

process-test-resources

4.test

test-compile    编译测试源代码(默认是test目录下)

process-test-class

执行单元测试，用合适的测试框架来进行测试，测试compile中编译出来的代码

5.package

 获取compile中编译好的代码并将其打包成可分类的格式，

prepare-package  将工程文件打包为指定的格式，例如JAR，WAR等

6.vertify

检查package是否有效、符合标准

7.install

将包安装至本地仓库，以让其它项目依赖

9.deploy

将最终的包复制到远程的仓库，以让其它开发人员与项目共享。

10.site

pre-site     执行一些需要在生成站点文档之前完成的工作

site    生成项目的站点文档

post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

site-deploy     将生成的站点文档部署到特定的服务器上

 

背景知识

maven对构建(build)的过程进行了抽象和定义，这个过程被称为构建的生命周期(lifecycle)。生命周期(lifecycle)由多个阶段(phase)组成,每个阶段(phase)会挂接一到多个goal。goal是maven里定义任务的最小单元，相当于ant里的target。

Mojo

Mojo 就是Maven plain Old Java Object。每一个 Mojo 就是 Maven 中的一个执行目标（executable goal），而插件则是对单个或多个相关的 Mojo 做统一分发。一个 Mojo 包含一个简单的 Java 类。插件中多个类似 Mojo 的通用之处可以使用抽象父类来封装。

 

以phase为目标构建

以phase为目标进行构建是最常见的，如我们平时经常执行的mvn compile、mvn test、mvn package等等,compile、test、package都是maven生命周期(lifecycle)里的phase，通过mvn命令，你可以指定一次构建执行到那一个阶段，在执行过程中，所有经历的执行阶段(phase)上绑定的goal都将得到执行。例如，对于一个jar包应用，当执行mvn package命令时，maven从validate阶段一个阶段一个阶段的执行，在执行到compile阶段时，compiler插件的compile goal会被执行，因为这个goal是绑定在compile阶段(phase)上的。这一点可从其对应的mojo类上得知：

 

再比如经常使用的打包插件shade，它的goal是绑定到package阶段的，这样，使用mvn package进行打包时都会执行shade的。

以goal为目标构建

虽然以phase为目标的构建最常见，但是有时候我们会发现，一些插件的goal并不适合绑定到任何阶段(phase)上，或者是，这些goal往往是单独执行，不需要同某个阶段(phase)绑定在一起，比如hibernate插件的导入\导出goal多数情况下是根据需要要手动执行的(当然，也可以绑定到某个阶段上，比如进行单元测试时，可考虑将其绑定到test阶段上)。再比如jetty(6.1.26)插件，它的goal都是将打包或未打包的工程部署到jetty里然后启动jetty容器的，多数情况下，人们都是独立运行这些goal的，比如：人们希望当键入mvn jetty:run后，工程就能完成编译后启动jetty,而jetty插件也确实是这样做的，它的run goal的mojo是这样声明的：

抛开mojo不讲，lifecycle与phase与goal就是级别的大小问题，引用必须是从高级引用下级（goal绑定到phase，也可理间为phase引用goal，只是在具体绑定时，不会phase定义引用哪些goal，但是执行是，却是phase调用绑定到它那的goal），也不能跨级引用，如lifecycle可以引用任意的phase，不同lifecycle可以同时引用相同的phase，lifecycle不能跨级引用goal。goal会绑定到任意的phase中，也就是说不同的phase可以同时引用相同的goal，所以goal可以在一个lifecycle里被重复执行哦，goal自然也不能说绑定到lifecycle中，它们三者的关系可以用公司里的 总领导，组领导，与职员的关系来解释