Maven实战读书笔记(四):Maven生命周期与插件

Maven的生命周期是对全部构建过程的抽象和统一。包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎全部构建步骤。算法

Maven的生命周期是抽象的,其实际行为是由插件来完成的,生命周期和插件二者协同合做,密不可分。apache

这种思想与设计模式中的模板方法很是类似。模板方法模式在父类定义算法的总体结构,子类经过实现或者重写父类的方法来控制实际行为,这样既能保证算法有足够的可扩展性,又能严格控制算法的总体结构。设计模式

4.1 生命周期

Maven拥有3套独立的生命周期:cleandefaultsite服务器

clean生命周期的目的是清理项目。框架

default生命周期的目的是构建项目。maven

site生命周期的目的是创建项目站点。post

每一个生命周期包含一些阶段(phase),这些阶段是有序的,后面的阶段会依赖于前面的阶段。单元测试

4.1.1 clean生命周期

clean生命周期的3个阶段:测试

1) pre-clean:执行一些清理前须要完成的动做spa

2) clean:清理上一次构建生成的文件

3) post-clean:执行一些清理后须要完成的动做

4.1.2 default生命周期:

1) validate

2) initialize

3) generate-sources

4) process-sources 处理项目主资源文件,通常来讲,是对src/main/resources目录的内容进行变量替换等工做,复制到项目输出的主classpath目录中。

5) generate-resources

6) process-resources

7) compile 编译项目的主源码到主classpath目录中。

8) process-classes

9) generate-test-sources

10) process-test-sources 处理项目测试资源文件,通常来讲,是对src/test/resources目录的内容进行变量替换等工做,复制到项目输出的测试classpath目录中。

11)generate-test-resources

12)process-test-resources

13) test-compile编译项目的测试源码到测试classpath目录中。

14) process-test-classes

15)test使用单元测试框架进行测试,测试代码不会被打包或部署

16) prepare-package

17) package 将编译好的代码,打包成可发布的格式,如jar

18) pre-integration-test

19)integration-test

20) post-integration-test

21) verify

22)install 将包安装到Maven本地仓库,供本地其余Maven项目使用

23) deploy 将最终的包复制到远程仓库,供其余开发人员和Maven项目使用

4.1.3 site生命周期

site生命周期的目的是创建和发布项目站点,Maven可以基于POM所包含的信息,自动生成一个友好的站点,方便团队交流和发布项目信息,含以下阶段:

1)pre-site执行一些在生成项目站点以前须要完成的工做

2)site 生成项目站点文档

3) post-site执行一些在生成项目站点以后须要完成的工做

4) site-deploy 将生成的项目站点发布到服务器上

4.2 插件目标

对于一个插件,为了复用代码,它每每可以完成多个任务,例如maven-dependency-plugin,可以分析项目依赖;列出项目依赖树;列出项目已解析的依赖,为这样每一个功能独立编写一个插件,显然是不可取的,由于这些功能背后有相同的代码,所以将这些功能汇集在一个插件里,每一个功能就是一个插件目标。

4.3 插件绑定

Maven的生命周期与插件相互绑定,用于完成实际的构建任务,具体而言,是生命周期的阶段与插件的目标相互绑定,以完成某个具体的构建任务。

下面是一些内置的绑定:

clean生命周期

maven-clean-plugin只有一个clean目标

site生命周期

项目的打包类型会影响构建的具体过程,所以default生命周期的阶段与插件目标的绑定关系由项目的打包类型所决定,下面以jar为示例:

default生命周期

除了内置绑定外,用户可以本身选择将某个插件目标绑定到生命周期的某个阶段上,以便在项目构建过程当中执行更丰富的任务。

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-source-plugin</artifactId>
   <version>2.1.1</version>
   <executions>
     <execution>
       <id>attach-source</id>
       <phase>verify</phase>
       <goals>
         <goal>jar-no-fork</goal>
       </goals>
     </execution>
   </executions>
</plugin>

除了基本的插件坐标配置,<executions>下的每一个<execution>用来配置执行一个任务。有时候,即便不配置<phase>阶段,插件目标也能绑定到生命周期中去,这是由于不少插件的目标在编写时已经定义了默认的绑定阶段,能够经过maven-help-plugin查看插件的详细信息:
mvn help:describe –Dplugin=org.apache.maven.plugins:maven-source-plugin:2.1.1 -Ddetail

4.4 插件解析机制

为了方便用户使用和配置插件,Maven不须要用户提供完整的插件坐标信息,就能够解析获得正确的插件。

与依赖构件同样,插件构件一样基于坐标存储在Maven仓库中,但Maven会区别对待依赖的远程仓库与插件的远程仓库。

经过<repositories>及其子元素<repository>能够配置依赖的远程仓库,插件的远程仓库须要使用<pluginRepositories><pluginRepository>进行配置。

默认状况下,若是该插件是Maven官方插件,则能够省略groupId(org.apache.maven.plugins),Maven在解析该插件的时候,会自动将groupId补上。

当插件没有添加版本号时,若该插件是核心插件,则在超级POM已经定义了版本号,若不是核心插件,Maven会遍历本地仓库和远程仓库,计算出latestrelease的值,Maven 2使用latest,但由于latest多是快照版本,Maven 3更改成使用release

相关文章
相关标签/搜索