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,如果还没有就检索用户自定义的插件组,
如果所有元数据中都不包含该前缀,则报错。