Maven 的插件和生命周期的绑定
一、Maven 的生命周期
Maven 的生命周期是对所有的构建过程进行抽象和统一。Maven 的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，生命周期只是定义了一系列的阶段，并确定这些阶段的执行顺序。
|
生命周期( Lifecycle ) |
阶段( Phase ) |
目标( Goa l) |
|
clean |
clean |
maven-clean-plugin:clean |
|
default |
process-resources |
maven-resources-plugin:resources |
|
compile |
maven-compiler-plugin:compile |
|
|
generate-test-resources |
maven-resources-plugin:testResouces |
|
|
test-compile |
maven-compiler-plugin:testCompile |
|
|
test |
maven-surefire-plugin:test |
|
|
package |
打包类型是jar时：maven-jar-plugin:jar； 打包类型是war时：maven-war-plugin:war |
|
|
install |
maven-install-plugin:install |
|
|
deploy |
maven-deploy-plugin:deploy |
|
|
site |
site |
maven-site-plugin:site |
|
site-deploy |
maven-site-plugin:deploy |
二、 Maven 插件和生命周期的绑定
Maven 的插件位于 ${REPOSITORY_HOME}\org\apache\maven\plugins 。用户和 Maven 最直接的交互方式就是调用这些生命周期阶段，而在执行这些阶段时，实际的任务主要由插件来完成。- 以 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 )绑定在一起，比如 jetty(6.1.26)插件，它的 goal 都是将打包或未打包的工程部署到 jetty 里然后启动 jetty 容器的，多数情况下，人们都是独立运行这些goal的，比如：人们希望当键入 mvn jetty:run 后，工程就能完成编译后启动 jetty。而 jetty 插件也确实是这样做的，它的 run goal 的 mojo 是这样声明的：
其中 @execute phase="test-compile" 指明 jetty:run 这一 goal 会促使 maven 先 build 到 test-compile 阶段，再执行这个 goal。同样，对于 jetty:run-war 这个goal 则要求先 build 到 package 阶段再执行该 goal。
而另外一个例子是exec插件的exec:java.
这个 goal 也声明了 execute 的 phase,但却是 validate，这样，如果代码没有编译，执行这个 goal 就会出错，所以多数情况下，人们总是使用下面的方式执行的：mvn clean compile exec:java
Maven 支持这种方式是因为有些任务不适合绑定到生命周期上。
在命令行调用插件的格式如下：
mvn groupId:artifactId:version:goal
其中 groupId、artifactId、version 共同表示了插件的坐标，goal 则表示插件目标的方法。
但我们看到很多执行插件目标的格式与之并不相符，例如文章开头的 mvn jetty:run，jetty并不是 groupId、artifactId或version 而是插件的前缀，这就有了第二种调用插件的格式：
mvn 前缀:goalMaven 通过查询插件仓库的元数据才得知插件前缀对应插件的 groupId、artifactId，而如果插件是Maven的核心插件则在超级POM中已经定义了插件的版本，如果不是核心插件，则默认取最新的release版本 。
Maven的插件仓库默认是 http://repo1.maven.org/maven2/org/apache/maven/plugins/ 和 http://repository.codehaus.org/org/codehaus/mojo/，相应的查询插件仓库元数据时会默认使用 org.apache.maven.plugins 和 org.codehaus.mojo 两个 groupId。但也可以通过配置 settings.xml 让Maven检查其他 groupId 上的插件仓库元数据，如：<settings> <pluginGroups> <pluginGroup>com.your.plugins</pluginGroup> </pluginGroups> </settings>
这样配置后，Maven就不只检查 org/apache/maven/plugins/maven-metadata.xml 和 org/codehaus/mojo/maven-metadata.xml，还会检查com/your/plugins/maven-metadata.xml
- 相关配置实例
如果我们想在 test 阶段只执行单元测试，而在 integration-test 阶段进行集成测试的话，可以如下配置：
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.10</version> <configuration> <skip>true</skip> </configuration> <executions> <execution> <id>run-test</id> <phase>test</phase> <goals> <goal>test</goal> </goals> <configuration> <skip>false</skip> <includes> <include>**/unit/**/*.java</include> </includes> </configuration> </execution> <execution> <id>run-integration-test</id> <phase>integration-test</phase> <goals> <goal>test</goal> </goals> <configuration> <skip>false</skip> <includes> <include>**/integration/**/*.java</include> </includes> </configuration> </execution> </executions> </plugin>
其中红色背景的 <skip>true</skip> 是为了让 Maven 的默认绑定(test阶段<-> maven-surefire-plugin:test 插件目标) 无效 (其实绑定仍然有效，只是执行时忽略执行罢了)，而后面的 executions 块内容则增加了两个绑定，分别将 maven-surefire-plugin:test 插件目标绑定到 test 阶段和 integration-test 阶段，只是配置不一样了，分别执行unit包和integration包下的测试类。
