Maven 插件机制

Maven 插件机制

 

Maven 的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构

件形式存在，所以 Maven 核心的分发包只有不到 3MB，Maven 会在需要的时候下载并使用插件。

 

1. 插件目标（plugin goal）

 

    对于插件本身，为了能够复用代码，它往往能够完成多个任务，

    为每个这样的功能编写一个独立的插件显然是不可取的，因为这些任务背后都有很多可以复用的代码，

    这些功能都聚集在一个插件里，每个功能就是一个插件目标。

 

    a） 通用写法

 

           冒号前面是插件前缀，冒号后面是该插件的目标。

           例如：dependency:list、compiler:compile。

 

2. 插件绑定

 

    Maven 的生命周期与插件相互绑定，用以完成实际的构建任务。更具体而言，

    是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。

    例如：项目编译这一任务，对应了 default 生命周期的 compile 这一阶段。

 

    a） 内置绑定

 

          为了让用户几乎不用任何配置就能构建 Maven 项目，Maven 在核心为一些主要的生命周期阶段，

          绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，

          对应的插件目标就会执行相应的任务。

          例如：clean 生命周期仅有 pre-clean、clean、post-clean 三个阶段。其中 clean与

                    maven-plugin:clean 绑定。maven-clean-plugin 仅有 clean 这一个目标，

                    其作用就是删除项目的输出目录。

 

           i.   clean 生命周期阶段与插件目标的绑定关系

 

生命周期阶段	插件目标
pre-clean
clean	maven-clean-plugin:clean
post-clean

           

           ii.  site 生命周期阶段与插件目标的绑定关系

 

生命周期阶段	插件目标
pre-site
site	maven-site-plugin:site
post-site
site-deploy	maven-site-plugin:deploy

           

           iii. default 生命周期阶段与插件目标的绑定关系

 

               相比 clean 和 site 生命周期来说，default 生命周期与插件目标的绑定关系就显得复杂一些。

               由于项目的打包类型会影响构建的具体过程，因此，default生命周期阶段与插件目标的绑定关系，

               由项目打包类型决定。例如：最常见的 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 生命周期还有很多其他阶段，

               默认他们没有绑定任何插件，因此也没有任何实际行为。除了默认的 jar 类型外，

               还有 war、pom、maven-plugin、ear 等。它们的default 生命周期与插件目标的绑定关系，

               可参阅 Maven 官方文档：http://maven.apache.org/guides/introduction/introduction-to-the-

                                                        lifecycle.html#Built-in_Lifecycle_Bind-ings。

 

           iv. 观察输出过程

               执行 mvn clean install 命令

               从输出可以看到，mvn clean install 实际调用了 clean 生命周期的pre-clean、clean 阶段，

               以及 default 生命周期的从 validate 至 install 所有阶段。

 

    b） 自定义绑定

 

           除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上，

           这种自定义绑定方式能让 Maven 项目在构建过程中执行更多、更丰富特色的任务。

 

           i.   创建项目的源码 jar 包

 

                内置的插件绑定关系中并没有设计这一任务，需要用户自行配置。

                maven-source-plugin 可以帮助我们完成该任务，它的 jar-no-fork 目标能

                够将项目的主代码打包成 jar 文件。可以将其绑定到 default 生命周期的verify 阶段上，

                在执行完集成测试后和安装构件之前创建源码 jar 包。

 

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

 

                1） 稳定性

                       对自定义绑定的插件，应该声明一个非快照版本来保证构建的稳定。

 

                2） execution

                       配置执行一个 id 为 attach-sources 的任务，通过 phase 配置绑定到verify 生命周期阶段上，

                       再通过 goals 配置指定要执行的插件目标。

 

                3） 默认绑定阶段

                       有很多插件的目标在编写时已经定义了默认绑定阶段，删除上面 phase一行配置，

                       再次执行 mvn verify，效果仍然一样。

 

                4） 执行顺序

                       当插件目标被绑定到不同的生命周期阶段，其执行顺序会由生命周期阶段的先后顺序决定。

                       如果多个目标被绑定到同一阶段，他们的执行会是？当多个插件目标绑定到同一阶段的时候，

                       这些插件声明的先后顺序决定了目标的执行顺序。

 

3. 插件配置

 

    完成了插件和生命周期的绑定之后，还可以配置插件目标的参数，进一步调整插件目标所执行的任务，

    几乎所有的 Maven 插件都有一些可配置的参数。

 

    a） 命令行配置

 

          在命令中使用-D 参数，并伴随一个参数键=参数值的形式配置。

          例如：install–Dmaven.test.skip=true。

 

          i.   –D 参数

               是 Java 自带，功能是通过命令行设置一个 Java 系统属性，Maven 简单地重用了该参数。

 

          ii.  maven-surefire-plugin

              maven-surefire-plugin 提供一个 maven.test.skip 参数，当其值为 true的时候，

              就会跳过执行测试。

 

    b） pom 中插件全局配置

 

           并不是所有插件参数都适合命令行配置，有些参数的值从项目创建到项目发布都不会改变，

           或者说很少改变，对于这种情况，在 pom 文件中一次性配置就显得比重复在命令行输入要方便。

           用户可以在声明插件的时候，对此插件进行一个全局的配置。也就是说，

           所有该基于该插件目标的任务，都会使用这些配置。

           例如：编译 Java 源文件版本。

 

           i.   编译 Java 源文件版本

 

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>1.6</source>
                <target>1.6</target>
            </configuration>
        </plugin>
    </plugins>
</build>

 

 

     c） pom 中插件任务配置

 

           除了为插件配置全局的参数，还可以为某个插件任务配置特定的参数。例如：

           maven-antrun-plugin，有一个 run 目标，可以用来在 Maven 中调用 Ant 任务。

           用户将 maven-antrun-plugin:run 绑定到多个生命周期阶段上，再加以不同的配置，

           就可以让 Maven 在不同的生命阶段执行不同的任务。

           代码：略。

 

4. 获取插件信息

 

    Maven 的插件非常多，而且大部分都没有完善的文档。正确的插件并进行正确的配置，

    其实不是一个简单的事情，要学会去哪里找合适的插件，以帮助完成任务。

 

    a） 在线插件信息

          i.   Apache

               http://maven.apache.org/plugins/index.html

          ii.  Codehaus

               http://mojo.codehaus.org/plugins.html

 

    b） 使用 maven-help-plugin 描述插件

 

           除了访问在线的插件文档外，还可以借助 maven-help-plugin 来获取插件的详细信息，

           可以运行如下命令来获取 maven-compiler-plugin2.1 版本的信息：

           mvn help: describe-Dplugin = org.apache.maven.plugins:maven-compiler-plugin:2.1

 

           i.   maven-help-plugin

                maven-help-plugin 的 describe 目标，在参数 plugin 中输入需要描述插件的 groupId、

                artifactId 和 version。Maven 在命令行输出maven-compiler-plugin 的简要信息，

                包含插件的坐标、目标前缀和目标等。

 

5. 目标前缀

 

    为了达到清晰、简洁的命令使用，Maven 引入了目标前缀的概念，

    help 是maven-help-plugin 的目标前缀，dependency 是 maven-dependency-plugin 的前缀，

    有了插件前缀，Maven 就能找到对应的 artifactId。不过，除了 artifactId，

    Maven 还需要 groupId 和 version 才能精确定位到某个插件。

 

6. 插件解析机制

 

    为了方便用户使用和配置插件，Maven 不需要用户提供完整的插件坐标信息，

    就可以解析得到正确的插件，有好处也有坏处，虽然简化了插件的使用和配置，

    可一旦插件出现异常行为，很难快速定位到出额外难题的插件构件。

 

    a） 插件仓库

 

          与依赖构件一样，插件构件同样基于坐标存储在 Maven 仓库中。

 

          i.   和依赖仓库区别

               Maven 会区别对待依赖的远程仓库和插件的远程仓库，与依赖的远程仓库配置不一样。

 

          ii.  插件远程仓库配置

 

<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <name>Maven Plugin Repository</name>
        <url>http://repo1.maven.org/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
</pluginRepositories>

 

          iii.  一般来说，中央仓库所包含的插件完全能满足我们的需要。

 

   b） 插件的默认 groupId

 

         在 pom 中配置插件的时候，如果该插件是 Maven 官方的插件

        （也就是说，如果其 groupId 为 org.apache.maven.plugins），就可以省略 groupId 配置。

 

   c） 解析插件版本

 

         如果用户没有提供插件的版本信息。

 

         i.   核心插件都预先设定了版本

 

         ii.  检查所有仓库中的可用版本做出选择

 

              maven-metadata.xml 元数据文件，latest 表示所有仓库中该构件的最新版本，

              release 表示最新的非快照版本。

 

              1） maven2

                    插件版本会解析至 latest。

              2） maven3

                    插件版本会解析至 release。

 

         iii. 依赖 Maven 解析插件版本其实是不推荐的做法

 

  d） 解析插件前缀

 

        插件前缀与groupId:artifactId是一一对应的，这种匹配关系存储在仓库元数据中，

        这里提到的仓库元数据。

 

        i.   groupId/maven-metadata.xml

             1） http://repo1.maven.org/maven2/org/apache/maven/plugins/

             2） http://repository.codehaus.org/org/codehaus/mojo/

 

        ii.  自定义检查其他groupId上的插件仓库元数据

 

<settings>
    <pluginGroups>
        <pluginGroup>com.your.plugins</pluginGroup>
    </pluginGroups>
</settings>

 

            Maven就会检查com/your/plugins/maven-metadata.xml

 

        iii. 举例说明（dependency:tree）

 

            首先基于默认的groupId归并所有插件仓库的元数据

            org/apache/maven/plugins/maven-metadata.xml，其次检查归并后的元数据，

            找到对应的artifactId为maven-dependency-plugin，然后结合当前元数据的groupId，

            org.apache.maven.plugins，再根据版本解析方式得到版本信息，最终得到完整的插件坐标。

            apache不包含就检索codehaus，如果还没有就检索用户自定义的插件组，

            如果所有元数据中都不包含该前缀，则报错。