Maven实战读书笔记（8） / 憋错料

何为Maven的生命周期？

1、Maven从大量项目和构建工具中学习和反思，然后总结了一套高度完善的、易扩展的生命周期

2、这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有的构建步骤

3、Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，实际的任务(如编译源代码)都是交由插件来完成的

Maven的这种思想与设计模式的模板方法非常相似

模板方法模式在父类中定义算法的整体结构，子类可以通过实现或者重写父类的方法来控制实际的行为，这样既保证了算法有足够的可扩展性，又能够严格控制算法的整体结构

模拟生命周期的模板方法抽象类

public abstract class AbstractBuild {

public void build() {

initialize();

compile();

test();

packages();

integrationTest();

deploy();

}

protected abstract void initialize();

protected abstract void compile();

protected abstract void test();

protected abstract void packages();

protected abstract void integrationTest();

protected abstract void deploy();

}

对上面的代码进行解释：

1、build()方法定义了整个构建的过程，依次初始化、编译、测试、打包(由于package 与Java关键字冲突，这里使用了单词packages)、集成测试和部署

2、但是这个类中没有具体实现初始化、编译、测试等行为，它们都交由子类去实现

Maven定义生命周期和插件机制的好处是？

1、保证了所有Maven项目有一致的构建标准

2、通过默认插件简化和稳定了实际项目的构建

3、此外，该机制还提供了足够的扩展空间，用户可以通过配置现有插件或者自行编写插件来自定义构建行为

Maven的三套生命周期

初学者往往会以为Maven的生命周期是一个整体，其实不然，Maven拥有三套相互独立的生命周期，它们分别为clean、default和site

1、clean生命周期的目的是清理项目

2、default生命周期的目的是构建项目

3、site的生命周期的目的是建立项目站点

声明周期与阶段(phase)

每个生命周期包含一些阶段 (phase)，这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段

clean生命周期的阶段有哪些？

clean生命周期，主要包含的阶段有pre-clean、clean和post-clean

当用户调用pre-clean的时候，只有pre-clean阶段得以执行

当用户调用clean的时候，pre-clean和clean阶段会以顺序执行

当用户调用post-clean的时候，pre-clean、clean和post-clean会得以顺序执行

注：生命周期阶段的前后是依赖关系，但三套生命周期本身是相互独立的，用户可以仅仅调用clean生命周期的某个阶段，或者仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响，例如，当用户调用clean生命周期的clean阶段的时候，不会触发default生命周期的任何阶段，反之亦然，当用户调用default生命周期的compile阶段的时候，也不会触发clean生命周期的任何阶段

clean生命周期的详细信息

clean生命周期的目的是清理项目，它包含三个阶段：

1、pre-clean执行一些清理前需要完成的工作

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

3、post-clean执行一些清理后需要完成的工作

default生命周期的详细信息

default生命周期定义了真正构建时所需要执行的所有步骤，它是所有生命周期中最核心的部分，其包含的阶段如下，只对重要的阶段进行解释：

1、validate

2、initialize

3、generate-sources

4、process-sources 处理项目主资源文件，一般来说，是对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中

5、generate-resources

6、process-resources

7、compile 编译项目的主源码。一般来说，是编译src/main/java目录下的Java文件至项目输出的主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 编译项目的测试代码。一般来说，是编译src/test/java 目录下的Java文件至项目输出的测试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项目使用

对于上面未解释的阶段，请参阅官方的解释:

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

site生命周期的详细信息

site生命周期的目的是建立和发布项目站点，Maven能够基于POM所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息

该生命周期包含如下阶段：

1、pre-site 执行一些在生成项目站点之前需要完成的工作

2、site 生成项目站点文档

3、post-site 执行一些在生成项目站点之后需要完成的工作

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

命令行与生命周期

从命令行执行Maven任何的最主要方式就是调用Maven的生命周期阶段，需要注意的是，各个生命周期是相互独立的，而一个生命周期的阶段是有前后依赖关系的。

下面以一些常见的Maven命令为例，解释其执行的生命周期阶段：

1、mvn clean：该命令调用clean生命周期的clean阶段，实际执行的阶段为clean生命周期的pre-clean和clean阶段

2、mvn test：该命令调用default生命周期的test阶段，实际执行的阶段为default生命周期的validate、initialize等，直到test的所有阶段，这也解释了为什么在执行测试的时候，项目的代码能够自动得以编译

3、mvn clean install：该命令调用clean生命周期的clean阶段和default生命周期的install阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段，以及default生命周期的从validate至install的所有阶段。该命令结合了两个生命周期，在执行真正的项目构建之前清理项目是一个很好的实践

4、mvn clean deploy site-deploy：该命令调用clean生命周期的clean阶段、default生命周期的deploy阶段，以及site生命周期的site-deploy阶段。实际执行的阶段为clean生命周期的pre-clean、clean阶段，default生命周期的所有阶段，以及site生命周期的所有阶段。该命令结合了Maven所有三个生命周期，且deploy为default生命周期的最后一个阶段，site-deploy为site生命周期的最后阶段

Maven的核心

Maven的核心仅仅定义了抽象的生命周期，具体的任务是交由插件完成的，插件以独立的构件形式存在，因此，Maven核心的分发包只有不到3MB的大小，Maven会在需要的时候下载并使用插件

举例说明插件maven-dependency-plugin

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

maven-dependency-plugin插件能够基于项目依赖做很多事情：

1、它能够分析项目依赖，帮助找出潜在的无用依赖

2、它能列出项目的依赖树，帮助分析依赖来源

3、它能够列出项目所有已解析的依赖等等

那么，为什么这样设计，一个插件有很多功能呢？

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

maven-dependency-plugin插件的目标是指？

maven-dependency-plugin有十多个目标，每个目标对应了一个功能，上述提到几个功能分别对应的插件目标为dependency：analyze、dependency:tree和dependency:list，这是一种通用的解法，冒号前面是插件前缀，冒号后面是该插件的目标。类似地，还可以写出compile:compile （这是maven-compiler-plugin的compile目标）和surefire:test （这是maven-surefire-plugin的test目标）

什么是插件绑定？

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

例如：项目编译这一任务，它对应了default生命周期的compile这一阶段，而maven-compile-plugin这一插件的compile目标能够完成该任务，因此，将它们绑定，就能实现项目编译的目：

生命周期阶段与插件目标绑定

为什么需要内置绑定？

为了能让用户几乎不用任何配置就能构建Maven项目，Maven的核心为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务

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

clean生命周期仅有pre-clean、clean和post-clean三个阶段，其中的clean与maven-clean绑定。maven-clean-plugin仅有clean这一个目标，其作用就是删除项目的输出目录

生命周期阶段	插件目标
Pre-clean
Clean	Maven-clean-plugin:clean
Post-clean

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

site生命周期有pre-site、site、post-site和site-deploy四个阶段，其中，site和maven-site-plugin:site相互绑定，site-deploy和maven-site-plugin:depoy相互绑定。maven-site-plugin有很多目标，其中，site目标用来生成项目站点，deploy目标用来将项目站点部署到远程服务器上

生命周期阶段	插件目标
Pre-site
Site	Maven-site-plugin:site
Post-site
Site-deploy	Maven-site-plugin:deploy

default生命周期与插件目标的绑定关系

default生命周期与插件目标的绑定关系要稍微复杂一些，这是因为对于任何项目，例如jar项目和war项目，它们的项目清理和站点生成任务是一样的，不过构建过程会有区别，jar项目需要打成jar包，而war项目需要打包war包

由于项目的打包类型会影响构建的具体过程，因此，default生命周期的阶段与插件目标的绑定关系由项目打包类型决定，打包类型是通过POM中的packing元素定义的。最常见、最重要的打包类型是jar，它也是默认的打包类型

default生命周期的内置插件绑定欢喜及具体任务 (打包类型：jar)

生命周期阶段	插件目标	执行任务
Process-resources	Maven-resources-plugin:resources	复制主资源文件至主输出目录
Compile	Maven-compiler-plugin:compile	编译主代码至主输出目录
Process-test-resources	Maven-resources-plugin:testResources	复制测试资源文件至测试输出目录
Test-compile	Maven-compile-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，还有其他说明你的吗？

除了默认的打包类型jar，常见的打包类型还有war、pom、maven-plugin、ear等

他们的default生命周期与插件目标的绑定关系可参阅Maven官方文档:

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in_Lifecycle_Bindings

什么是自定义绑定方式？

除了内置绑定以外，用户还能够自己选择将某个插件目标绑定到生命周期的某个阶段上，这种自定义绑定方式能让Maven项目在构建过程中执行更多更丰富特色的任务

一个常见的例子

一个常见的例子是创建项目的源码jar包，内置的插件绑定关系中并没有涉及这一任务，因此需要用户自行配置

maven-source-plugin可以帮助我们完成该任务，它的jar-no-fork目标能够将项目的主代码打包成jar文件，可以将其绑定到default生命周期的verify阶段上，在执行完集成测试后和安装构件之前创建源码jar包

配置如下

<build>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-source-plugin</artifactId>

<id>attach-sources</id>

<phase>verify</phase>

<goals>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

对上述配置进行解释：

1、在POM的build元素下的plugins子元素中声明插件的使用，该例中用到的是maven-source-plugin

2、其groupId为org.apache.maven.plugins，这也是Maven官方插件的groupId，紧接着artifactId为maven-source-plugin，version为2.1.1，对于自定义绑定的插件，用户总是应该声明一个非快照版本，这样可以避免由于插件版本变化造成的构建不稳定性

3、除了基本的插件坐标声明外，还有插件执行配置，executions下每个execution子元素可以用来配置执行一个任务

4、该例中配置了一个id为attach-sources的任务，通过phrase配置，将其绑定到verify生命周期阶段上，再通过goals配置指定要执行的插件目标

对于上述配置的一个细节需要注意

有时候，即使不通过phase元素配置生命周期阶段，插件目标也能够绑定到生命周期中去。例如，可以尝试删除上述配置中的phase一行，再次执行mvn verify，仍然可以看到maven-source-plugin:jar-no-fork得以执行，出现这种现象的原因是:有很多插件的目标在编写时已经定义了默认绑定阶段。可以使用maven-help-plugin查看插件详细信息，了解插件目标的默认绑定阶段

如何使用maven-help-plugin插件查看插件目标的默认绑定阶段？

执行命令：

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

需要在pom.xml目录执行此命令

在列出的信息中可能会出现，Bound to phase:package一行，它表示该目标默认绑定的生命周期阶段(这里是package)，也就是说，当用户配置使用maven-source-plugin的jar-no-fork目标的时候，如果不指定phase参数，该目标就会被绑定到package阶段

如果多个目标被绑定到同一个阶段，它们的执行顺序会是怎样？

当多个目标被绑定到同一个阶段，这些插件声明的先后顺序决定了目标的执行顺序

关于插件目标的配置

完成了插件和生命周期的绑定，用户还可以配置插件目标的参数，进一步调整插件目标所执行的任务，以满足项目的需求。几乎所有的Maven插件的目标都有一些可配置的参数，用户可以通过命令行和POM配置等方式来配置这些参数

如何使用命令行的方式修改插件的配置？

在日常Maven使用中，我们会经常从命令行输入并执行Maven命令。在这种情况下，如果能方便地更改某些插件的行为，无疑会十分方便

很多插件目标的参数都支持从命令行配置，用户可以在Maven命令中使用-D参数，并伴随一个参数键 = 参数值的形式，来配置插件目标的参数

例如，maven-surefire-plugin提供了一个maven.test.skip参数，当其值为true的时候，就会跳过执行测试，于是，在运行命令的时候，加上如下-D参数就能跳过测试：

mvn install -Dmaven.test.skip=true

这里的-D参数是什么意思？

参数-D是Java自带的，其功能是通过命令行设置一个Java系统属性，Maven简单地重用了该参数，在准备插件的时候检查系统属性，便实现了插件参数的配置

POM中插件全局配置

并不是所有的插件参数都适合从命令行配置，有些参数的值从项目创建到项目发布都不会改变，或者说很少改变，对于这种情况，在POM文件中一次性配置就显然比重复的命令行输入要方便

比如，我们通常会需要配置maven-compiler-plugin告诉它编译Java 1.7版本的源文件，生成与JVM 1.5兼容的字节码文件

在POM中对插件进行全局配置

<build>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

</configuration>

</plugin>

</plugins>

</build>

这样，不管绑定到compile阶段的maven-compiler-plugin:compile任务，还是绑定到test-compile阶段的maven-compiler-plugin:testCompiler任务，就都能够使用该配置，基于Java1.7版本进行编译

POM中插件任务配置

除了为插件配置全局的参数，用户还可以为某个插件任务配置特定的参数。以maven-antrun-plugin为例，它有一个目标run，可以用来在Maven中调用Ant任务。用户将maven-antrun-plugin:run绑定到多个生命周期阶段上，再加以不同的配置，就可以让Maven在不同的生命阶段执行不同的任务

在POM中对插件进行任务配置

<build>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-antrun-plugin</artifactId>

<id>ant-validate</id>

<phase>validate</phase>

<goals>

</goals>
<configuration>

<tasks>

<echo>I‘m bound to validate phase.</echo>

</tasks>

</configuration>

</execution>

<id>ant-verify</id>

<phase>verify</phase>

<goals>

</goals>
<configuration>

<tasks>

<echo>I‘m bound to verify phase.</echo>

</tasks>

</configuration>

</execution>

</executions>

</plugin>

</plugins>

</build>

对上述配置进行解释：

1、maven-antrun-plugin:run与validate阶段绑定，从而构成一个id为ant-validate的任务

2、插件全局配置中的configuration元素位于plugin元素下面，而这里的configuration元素则位于execution元素下，表示这是特定任务的配置，而非插件整体的配置

3、这个ant-validate任务配置了一个echo Ant任务，向命令行输出一段文字，表示该任务是绑定到validate阶段的，第二个任务的id为ant-verify，它绑定到了verify阶段，同样它也输出一段文字到命令行，告诉该任务绑定到了verrify阶段

关于插件存在的问题说明

仅仅理解如何配置使用插件是不够的，当遇到一个构建任务的时候，用户还需要知道去哪里寻找合适的插件，以帮助完成任务。找到正确的插件之后，还要详细了解该插件的配置点。由于Maven的插件非常多，而且这其中的大部分没有完善的文档，因此，使用正确的插件并进行正确的配置，其实并不是一件容易的事

如何在线查找插件信息？

基本上所有的主要的Maven插件都来自Apache和Codehaus，由于Maven本身是属于Apache软件基金会的，因此它有很多官方的插件，每天都有成千上万的Maven用户在使用这些插件，它们具有非常好的稳定性

详细的列表地址：

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

所有官方插件下载地址：

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

托管于Codehaus上的Mojo项目

除了Apache上的官方插件之外，托管于Codehaus上的Mojo项目也提供了大量的Maven插件，需要注意的是，这些插件的文档和可靠性相对较差

详细列表可以访问地址：

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

Codehaus的Maven插件下载地址:

http://repository.codehaus.org/org/code-haus/mojo/

另外，上述两个站点提供的插件非常多，而实际使用中常用的插件远不会是这个数量

使用maven-help-plugin描述插件

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

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

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

你可能会发现一行Goal Prefix: compiler，这是目标前缀 (Goal Prefix)，其作用是方便在命令行直接运行插件，maven-compiler-plugin的目标前缀是compiler

在描述插件的时候，还可以省去版本信息，让Maven自动获取最新版本来进行表述：

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

进一步简化

mvn help:describe -Dplugin= compiler

如果想仅仅描述某个插件目标的信息，可以加上goal参数

mvn help:describe -Dplugin= compiler -Dgoal=compile

如果想让maven-help-plugin输出更详细的信息，可以加上detail参数:

mvn help:describe -Dplugin= compiler -Ddetail

使用mvn -h来显示mvn命令帮助

你可能会看到如下信息：

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

Options:

...

该信息告诉我们mvn命令的基本用法，options表示可用的选项，mvn命令有20多个选项

除了选项外，mvn命令后面可以添加一个或者多个goal和phase，它们分别是指插件目标和生命周期阶段

为什么Maven支持直接从命令行调用插件目标？

Maven支持这种方式是因为有些任务不适合绑定在声明周期上

例如maven-help-plugin:describe，我们不需要在构建项目的时候描述插件信息

又如maven-dependency-plugin:tree，我们也不需要在构建项目的时候去显示依赖树

那么如何使用上述两个插件目标？

你可以在命令行输入：

mvn help:describe -Dplugin=compiler

mvn dependency:tree

上面的两条命令有个疑问？

describe是maven-help-plugin的目标没错，但冒号前面的help是什么呢？它既不是groupId、也不是artifactId？

Maven是如何根据该信息找到对应版本插件的呢？

为什么不是maven-dependency-plugin:tree，而是dependency:tree？

尝试回答上述问题，执行下面两条命令：

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

mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:tree

这两条命令比较好理解，插件的groupId、artifactId、version以及goal都得以清晰描述

它们的效果与之前的两个命令基本是一样的，但显然前面的命令更加简洁

为了达到该目的，Maven引入了目标前缀的概念

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

dependency是maven-dependency-plugin的前缀

有了插件前缀，Maven就能找到对应的artifactId，不过，除了artifactId，Maven还需要得到groupId和version才能精确定位到某个插件，如何解释这个过程？

Maven插件解析机制

为了方便用户使用和配置插件，Maven不需要用户提供完整的插件坐标信息，就可以解析得到正确的插件，Maven的这一特性是一把双刃剑，虽然它简化了插件的使用和配置，可一旦插件的行为出现异常，用户就很难快速定位到处问题的插件构件

例如mvn help:system这样一条命令，它到底执行了什么插件？该插件的groupId、artifactId和version分别是什么？这个构件是从哪里来的？等等问题

插件仓库

与依赖构件一样，插件构件同样基于坐标存储在Maven仓库中，在需要的时候，Maven会从本地仓库寻找插件，如果不存在，则从远程仓库查找，找到插件之后，再下载到本地仓库使用

Maven会区别对待依赖的远程仓库和插件的远程仓库

1、当Maven需要的依赖在本地仓库不存在时，它会去所配置的远程仓库查找

2、当Maven需要的插件在本地仓库不存在时，它就不会去这些远程仓库查找

3、不同于repositories及其repository子元素，插件的远程仓库使用pluginRepositories和PluginRepository配置

Maven内置的插件仓库配置

<id>central</id>

<name>Maven Plugin Repository</name>

<url>http://repo1.maven.org/maven2</url>

<layout>default</layout>

<enabled>false</enabled>

</snapshots>

<updatePolicy>never</updatePolicy>

</releases>

</pluginRepository>

</pluginRepositories>

关于插件仓库的说明

1、一般中央仓库所包含的插件完全够用，不需要配置其他插件仓库

插件的默认groupId

1、在POM中配置插件的时候，如果该插件是Maven的官方插件，即(如果其groupId为org.apache.maven,plugins)，就可以省略groupId配置。比如像下面这样：

<build>

<artifactId>maven-compiler-plugin</artifactId>

</configuration>

</plugin>

</plugins>

</build>

2、不推荐使用这一机制

Maven的解析插件版本机制

同样是为了简化插件的配置和使用，在用户没有提供插件版本的情况下，Maven会自动解析插件版本

1、Maven在超级POM中为所有核心插件设定了版本，超级POM是所有Maven项目的父POM，所有项目都继承这个超级POM的配置，因此，即使用户不加任何配置，Maven使用核心插件的时候，它们的版本就已经确定了。这些插件包括maven-clean-plugin、maven-compiler-plugin、maven-surefire-plugin等

2、如果用户使用某个插件时没有设定版本，而这个插件又不属于核心插件的范畴，Maven就会去检查所有的仓库中可用的版本，然后做出选择，以maven-compiler-plugin为例，它在中央仓库的仓库元数据为:

http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata.xml，其代码如下：

<?xml version="1.0" encoding="UTF-8"?>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

</versions>

</versioning>

</metadata>

3、Maven遍历本地仓库和所有的远程插件仓库，将该路径下的仓库元数据归并后，就能计算出lastest和release的值。lastest表示所有仓库中该构件的最新版本，而release表示最新的非快照版本。在Maven 2中，插件的版本会被解析至latest，也就是说，当用户使用某个非核心插件且没有声明版本的时候，Maven会将版本解析为所有可用仓库中的最新版本，而这个版本也可能是快照版本

4、当插件的版本为快照版本时，就会出现潜在的问题。Maven会基于更新的策略，检查并使用快照的更新。某个插件可能昨天还用的好好的，今天就出错了，其原因就是这个快照版本的插件发生了变化。为了防止这类问题，Maven3调整了解析机制，当插件没有声明版本的时候，不再解析至latest，而是使用release。这样就可以避免由于快照频繁更新而导致的插件行为不稳定

5、依赖Maven解析插件版本其实是不推荐的做法，即使Maven 3将版本解析到最新的非快照版，也还是会有潜在的不稳定性。例如，可能某个插件发布了一个新的版本，而这个版本的行为与之前的版本发生了变化，这种变化可能导致项目构建失败。因此，使用插件的时候，应该一直显式地设定版本，这也解释了Maven为什么要在超级POM中为核心插件设定版本

Maven如何解析插件前缀？

前面说到mvn命令行支持使用插件前缀来简化插件的调用，现在解释Maven如何根据插件前缀解析得到插件的坐标

插件前缀与groupId:artifactId是一一对应的，这种匹配关系存储在仓库元数据中。与之前提到的groupId/artifactId/maven-metadata.xml不同，这里的仓库元数据为groupId/maven-metadata.xml，那么这里的groupId是什么呢？

我们知道，插件都位于以下两个地址：

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

http://repository.codehaus.org/org/code-haus/mojo/

相应地，Maven在解析插件仓库元数据的时候，会默认使用org.apache.maven.plugins和org.codehaus.mojo两个groupId，也可以通过配置settings.xml让Maven检查其他groupId上的插件仓库元数据:

<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

插件仓库元数据

<name>Maven Clean Plugin</name>

<prefix>clean</prefix>

<artifactId>maven-clean-plugin</artifactId>

</plugin>

<name>Maven Compiler Plugin</name>

<prefix>compiler</prefix>

<artifactId>maven-compiler-plugin</artifactId>

</plugin>

<name>Maven Dependency Plugin</name>

<prefix>dependency</prefix>

<artifactId>maven-dependency-plugin</artifactId>

</plugin>

</plugins>

</metadata>

对于上述配置的解释：

1、上述内容是从中央仓库的org.apache.maven.plugins.groupId下插件仓库元数据中截取的一些片段，从这段数据中就能看到maven-clean-plugin的前缀为clean，maven-compiler-plugin的前缀为compiler，maven-dependency-plugin的前缀为dependency

Maven是如何解析dependency:tree这样的命令的？

1、当Maven解析到dependency:tree这样的命令后，它首先基于默认的groupId归并所有插件仓库的元数据org/apache/maven/plugins/maven-metadata.xml

2、其次检查归并后的元数据，找到对应的artifactId为maven-dependency-plugin；然后结合当前元数据的groupId org.apache.maven.plugins，然后通过上面的解析插件版本，解析到version，这时就得到了完整的插件坐标

3、如果org/apache/maven/plugins/maven-metadata.xml没有记录该插件的前缀，则接着检查其他groupId下的元数据，如org/codehaus/mojo/maven-metadata.xml，以及用户自定义的插件组，如果所有的元数据中都不含该前缀，则报错

时间： 2024-08-05 04:44:27

Maven实战读书笔记（8）

Maven实战读书笔记（8）的相关文章

Maven实战读书笔记（15）

Maven实战读书笔记（3）

Maven实战读书笔记（13）

maven实战读书笔记（1）

Maven实战读书笔记（14）

Maven实战读书笔记（12）- Nexus

Maven实战读书笔记（6）

Maven实战读书笔记（18）

Maven实战读书笔记（7）