6. maven的生命周期和插件(二)

晓之木初

已于 2022-04-25 14:14:17 修改

阅读量187

点赞数

分类专栏： # 《maven实战》文章标签： maven

于 2021-03-26 00:44:29 首次发布

本文链接：https://blog.csdn.net/u014454538/article/details/115221290

版权

《maven实战》专栏收录该内容

11 篇文章 2 订阅

订阅专栏

1. maven插件的配置

1.1 maven命令中配置插件

还记上一篇博客，出现过如下命令，用于查看某个插件的信息

mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:3.0.1 -Ddetail

该命令指定需要查看信息的plugin为org.apache.maven.plugins:maven-source-plugin:3.0.1，并且查看其详细信息（-Ddetail）。
还有，在install项目时，我们经常指定maven.test.skip参数，让maven跳过单元测试。
```
mvn clean install -Dmaven.test.skip=true
```
而最近自己在进行Java编程的过程中也发现了，使用idea运行某个main方法时，可以在vm options中配置一些参数。例如，-Dpassword=12345678。
原来，这是在设置Java的系统属性，通过System.getProperty("password")便可以获得12345678这个值。
相当于，Java系统属性的设置可以通过-Dproperty=property_value来实现
不难看出，上面的maven命令也是使用了Java系统属性来向help插件的describe插件目标传递参数，从而达到配置插件的目的。
什么是配置插件？
其实，所谓的配置插件，其实是通过参数来配置插件目标，让插件目标执行特定的任务。
在maven’命令中，通过-D来配置插件目标，一次性的配置方式。

1.2 pom文件中全局地配置插件

如果，我想让插件中的所有插件目标在运行时，都拥有相同的配置，且每次执行时都不用通过-D进行一次性配置呢？
解决方法： 在pom文件中全局地配置插件
例如，我们之前遇到过的给compiler插件配置source和target的jdk版本，就是在对插件进行全部配置。这样，无论是执行compiler:compile，还是执行compiler:testCompile时，都会按照指定的jdk版本去完成编译任务。

1.3 pom文件中局部地配置插件

所谓局部的配置插件，其实就是配置插件中的某些插件目标，从而让插件目标执行特定的任务
PS： 无论是全局配置，还是局部配置，书上都有具体的配置实例。但是自己并未使用过局部配置，因此对局部配置的感受并不深

2. 获取插件信息

2.1 从网站上获取插件信息

基本上所有的maven插件都来自Apache和Codehaus，如果说官方插件，那肯定是Apache提供的插件（毕竟大名鼎鼎的Apache基金会😂）
Apache提供的插件，具有非常好的稳定和完善的文档，官方网站为：https://maven.apache.org/plugins/index.html
而托管于Codehaus上的Mojo项目也提供了很多maven插件，但其插件的文档和稳定性相对较差
在Apache插件的首页，我们点击surefire插件，以此为例，看看其文档有哪些内容。

surefire插件拥有的插件目标：
点击surefire:test这一插件目标，我们可以看该插件目标的具体信息，包括插件目标的参数、参数类型、等信息
其中，有一个skip参数。其中user property的值，就是我们在Maven命令中使用该参数时的-D属性。—— 注意： 并非所有插件目标的参数都会有对应的user property，这时只能在pom文件中配置这些参数的值。

2.2 使用maven-help-plugin查看插件信息

文章开始处，我们就有如何使用maven-help-plugin查看插件信息的例子
主要有以下参数可以尽心配置：
① -Dplugin：指定想要信息的插件
② -Dgoal：指定查看插件中某个插件目标的信息
③ -Ddetail：指定查看详细信息
之前我们说过，maven中定位一个构件，依靠的基本坐标是groupId、artifactId和version，而我们在使用maven-help-plugin时，只是使用了一个简写help
我在上一篇博客，还是这是插件名的关键字，其实这是插件的目标前缀。
后面，我们将会详细讲解，如果通过插件的目标前缀，获取到插件的坐标，从而完整的定位插件。

2.3 在maven命令中使用插件（目标）

maven命令的使用方式如下：

$ mvn -h

usage: mvn [options] [<goal(s)>] [<phase(s)>]

可以看到，我们除了通过指定生命周期阶段（phase)触发插件目标，还可以直接指定插件目标。
因为，有一些插件目标其实并不适合与生命周期阶段绑定。
例如，查看项目已解析的依赖列表，这与项目的构建完全没有关系，无法与生命周期阶段绑定。
像help:describe、dependency:tree、dependency:list等，其实都是在maven命令中直接使用插件目标

3. 插件的解析机制

3.1 插件仓库

我们之前提到过，无论是从远程仓库下载依赖、还是上传依赖，都可以通过在pom文件中配置<repository>来实现。必要时，我们还会在settings.xml文件中，配置仓库镜像
与依赖一样：
① 插件也作为构件存储在maven仓库中
② 插件解析时，也是优先查找本地仓库；本地仓库没有，会查找远程仓库，下载插件至本地再使用
③ 但是，插件的远程仓库一般无需专门配置，使用maven内置的插件远程仓库配置即可。

3.2 插件的目标前缀

插件的目标前缀，对应插件信息中Goal Prefix。例如，org.apache.maven.plugins:maven-source-plugin:3.0.1的目标前缀是source

Name: Apache Maven Source Plugin
Description: The Maven Source Plugin creates a JAR archive of the source
  files of the current project.
Group Id: org.apache.maven.plugins
Artifact Id: maven-source-plugin
Version: 3.0.1
Goal Prefix: source

# 插件目标节选
source:aggregate
  Description: Aggregate sources for all modules in an aggregator project.
  Implementation: org.apache.maven.plugins.source.AggregatorSourceJarMojo
  Language: java
  Bound to phase: package
  Before this goal executes, it will call:
    Phase: 'generate-sources'

插件信息中，我们也可以看出，每个插件目标，确实是以目标前缀:插件名表示的
在maven的插件机制中，与目标前缀绑定是插件的artifactId。
下面，我们详细介绍，groupId和version是如何获取的

3.3 插件的groupId

maven插件是有默认的groupId的，首选是apache官方的groupId：org.apache.maven.plugins
其次，是Mojo的groupId：org.codehaus.mojo
最后，是用户在pom文件或setting.xml中，为插件配置的远程仓库的groupId
因此，一般如果使用Apache的官方插件，可以省略其groupId

3.4 插件的version

首先，maven在超级pom中为所有核心插件设置了version
其次，如果用户没有设置version并且插件不是核心插件，maven有自己的version确定机制：
① maven 2中根据仓库元数据，获取LATEST的version，这会导致插件的不稳定
② maven 3中根据仓库元数据，获取RELEASE的version，这也存在潜在风险：插件版本的更新，意味着插件的行为变化，可能会导致项目构建失败。
总结： 在使用maven插件时，还是显示指定插件版本比较稳妥！！

3.5 插件的解析机制

插件的目标前缀是与插件的artifactId绑定的，可以从插件仓库的元数据信息看出。下面是clean插件的部分元数据信息。
```
...
<prefix>clean</prefix>
<artifact>maven-clean-plugin</artifact>
...
```

在解析插件时：

基于默认的groupId获取远程仓库的元数据并合并至本地。如果有三个默认的groupId，则会有三份对应的仓库元数据
首先基于Apache groupId对应的元数据，查找artifactId。如果没有找到，则继续查找Mojo或用户自定义groupId的元数据，去查找artifact。
如果找到了对应的artifact，则此时便获得了groupId；如果，都未找到则报错。（利用artifact反向查找groupId)
有了groupId，而version则是通过上一小节中的机制去获取的。
因此，groupId、artifactId和version都找到了，也就是能定位插件了。