为了方便用户使用和配置插件,Maven不需要用户提供完整的插件坐标信息,就可以解析得到正确的插件,Maven的这一特性是一把双刃剑,虽然他简化了插件的使用和配置,可一旦插件的行为出现异常,用户就很难快速定位到问题的插件构件。例如mvn help:system这样一条命令,他到底执行了什么插件?该插件的groupId、artifactId和version分别是什么?这个构件是从哪里来的?本文就详细介绍Maven的运行机制,以让其不仅知其然,更知其所以然。
插件仓库
与依赖构件一样,插件构件同样基于坐标存储在Maven仓库中。在需要的时候,Maven会从本地仓库寻找插件,如果不存在,则从远程仓库查找。找到插件之后,再下载到本地仓库使用。
值得一提的是,Maven会区别对待依赖的远程仓库与插件的远程仓库。当Maven需要的依赖在本地仓库不存在时,他会去所配置的远程仓库查找,可是当Maven需要的插件在本地仓库不存在时,他就不会去这些远程仓库查找。
不同于repositories及其repository子元素,插件的远程仓库使用pluginRepositories和pluginRepository配置。例如,Maven内置了如下的插件远程仓库配置,见下面所示。
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Maven Plugin Repository</name>
<url>http://repo1.maven.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>
除了pluginRepositories和pluginRepository标签不同之外,其余所有子元素表达含义与依赖远程仓库配置完全一样。我们甚至看到,这个默认插件仓库的地址就是中央仓库,他关闭了对SNAPSHOT的支持,以防止引入SNAPSHOT版本的插件而导致不稳定的构建。
一般来说,中央仓库所包含的插件完全能够满足我们的需要,因此也不需要配置其他的插件仓库。只有在很少的情况下,项目使用的插件无法在中央仓库找到,或者自己编写了插件,这个时候可以参考上述的配置,在POM或者settings.xml中加入其他的插件仓库配置。
插件的默认groupId
在POM中配置插件的时候,如果该插件是Maven的官方插件(即如果其groupId为org.apache.maven.plugins),就可以省略groupId配置,见下面所示。
<build>
<plugins>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugins>
</build>
上述配置中省略了maven-compiler-plugin的groupId,Maven在解析该插件的时候,会自动用默认groupId org.apache.maven.plugins补齐。
不推荐使用Maven的这一机制,虽然这么做可以省略一些配置,但这样的配置会让团队中不熟悉Maven的成员感到费解,况且能省略的配置也就仅仅一行而已。
解析插件版本
同样是为了简化插件的配置和使用,在用户没有提供插件版本的情况下,Maven会自动解析插件版本。
首先,Maven在超级POM中为所有核心插件设定了版本,超级POM是所有Maven项目的父POM,所有项目都继承这个超级POM的配置,因此,即使用户不加任何配置,Maven使用核心插件的时候,他们的版本就已经确定了。这些插件包括maven-clean-plugin、maven-compiler-plugin、maven-surefire-plugin等。
如果用户使用某个插件时没有设定版本,而这个插件又不属于核心插件的范畴,Maven就会去检查所有仓库中可用的版本,然后做出选择。以maven-compiler-plugin为例,他在中央仓库的仓库元数据为http://repol.maven.org/maven2/org/apache/maven/plugins/maven-compiler/maven-metadata.xml,其内容如下所示。
<?xml version="1.0" encoding="UTF-8" ?>
<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<versioning>
<latest>2.1</latest>
<release>2.1</release>
<versions>
<version>2.0-beta-1</version>
<version>2.0</version>
<version>2.0.1</version>
<version>2.0.2</version>
<version>2.1</version>
</versions>
</versioning>
</metadata>
Maven遍历本地仓库和所有远程插件仓库,将该路径下的仓库元数据归并后,就能计算出latest和release的值。latest表示所有仓库中该构件的最新版本,而release表示最新的非快照版本。在Maven 2中,插件的版本会被解析至latest。也就是说,当用户使用某个非核心插件且没有声明版本的时候,Maven会将版本解析为所有可用仓库中的最新版本,而这个版本也可能是快照版。
当插件的版本为快照版本时,就会出现潜在的问题。Maven会基于更新策略,检查并使用快照的更新。某个插件可能昨天还用的好好的,今天就出错了,其原因就是这个快照版本的插件发生了变化。为了防止这类问题,Maven 3调整了解析机制,当插件没有声明版本的时候,不再解析至latest,而是使用release。这样就可以避免由于快照频繁更新而导致的插件行为不稳定。
依赖Maven解析插件版本其实是不推荐的做法,即使Maven 3 将版本解析到最新的非快照版,也还是会有潜在的不稳定性。例如,可能某个插件发布了一个新的版本,而这个版本的行为与之前的版本发生了变化,这种变化就可能导致项目构件失败。因此,使用插件的时候,应该一直显式的设定版本,这也解释了Maven为什么要在超级POM中为核心插件设定版本。
解析插件前缀
现在解释Maven如何根据插件前缀解析得到插件坐标。
插件前缀与groupId:artifactId是一一对应的,这种匹配关系存储在仓库元数据中。与groupId/artifactId/maven-metadata.xml不同,这里的仓库元数据为groupId/maven-metadata.xml,那么这里的groupId是什么呢?主要的插件都位于http://repol.maven.org/maven2/org/apache/maven/plugins和http://repository.codehaus.org/org/codehaus/mojo/,相应地,Maven在解析插件仓库元数据的时候,会默认使用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。
下面看一下插件仓库元数据的内容,见下面。
<metadata>
<plugins>
<plugin>
<name>Maven Clean Plugin</name>
<prefix>clean</prefix>
<artifactId>maven-clean-plugin</artifactId>
</plugin>
<plugin>
<name>Maven Compiler Plugin</name>
<prefix>compiler</prefix>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<name>Maven Dependency Plugin</name>
<prefix>dependency</prefix>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
</plugins>
</metadata>
上述内容是从中央仓库的org.apache.maven.plugins.groupId下插件仓库元数据中截取的一些片段,从这段数据中就能看到maven-clean-plugin的前缀为clean,maven-compiler-plugin的前缀为compiler,maven-dependency-plugin的前缀为dependency。
当Maven解析到dependency:tree这样的命令后,他首先基于默认的groupId归并所有插件仓库的元数据org/apache/plugins/maven-metadata.xml;其次检查归并后的元数据,找到对应的artifactId为maven-dependency-plugin;然后结合当前元数据的groupId为org.apache.maven.plugins;最后解析得到version,这时就得到了完整的插件坐标。如果org/apache/maven/plugins/maven-metadata.xml,以及用户自定义的插件组。如果所有元数据中都不包含该前缀,则报错。