maven3实战之仓库(从仓库解析依赖的机制)
----------
Maven是根据怎样的规则从仓库解析并使用依赖构件的呢?
当本地仓库没有依赖构件的时候,Maven会自动从远程仓库下载。当依赖版本为快照版本的时候,Maven会自动找到最新的的快照。这背后的依赖解析机制可以概括如下:
1.当依赖的范围是system的时候,Maven直接从本地文件系统解析构件。
2.根据依赖坐标计算仓库路径后,尝试直接从本地仓库寻找构件,如果发现相应构件,则解析成功。
3.在本地仓库不存在相应构件的情况下,如果依赖的版本是显式的发布版本构件,如:1.2,2.1等,则遍历所有的远程仓库,发现后,下载并解析使用。
4.如果依赖的版本是RELEASE或者LATEST,则基于更新策略读取所有远程仓库的元数据groupId/artifactId/mavenmetadata.xml,将其与本地仓库的对应元数据合并后,计算出RELEASE或者LATEST真实的值,然后基于这个真实的值检查本地和远程仓库,如步骤1和3。
5.如果依赖的版本是SNAPSHOT,则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/mavenmetadata.xml,将其与本地仓库的对应元数据合并后,得到最新快照版本的值,然后基于该值检查本地仓库,或者从远程仓库下载。
6.如果最后解析得到的构件版本是时间戳格式的快照,如:1.4-20091104.121450-121,则复制其时间戳格式的文件到非时间戳格式,如:SNAPSHOT,并使用该非时间戳格式的构件。
当依赖的版本不明晰的时候,如:RELEASE,LATEST和SNAPSHOT,Maven就需要基于更新远程仓库的更新策略来检查更新。在前面的仓库配置blog中,有一些配置与此有关;首先是<releases><enabled>和<snapshots><enabled>,只有仓库开启了对于发布版本的支持时,才能访问该仓库的发布版本构件信息,对于快照版本也是同理;其次要注意的是
<releases>和<snapshots>的子元素<updatePolicy>,该元素配置了检查更新的频率。最后,用户还可以从命令行加入参数-U,强制检查更新,使用参数后,Maven就会忽略<updatePolicy>的配置。
当Maven检查完更新策略,并决定检查依赖更新的时候,就需要检查仓库元数据maven-metadata.xml。回顾一下前面提到的RELEASE和LATEST版本,它们分别对应了仓库中存在的该构件的最新发布版本和最新版本(包含快照),而这两个"最新"是基于groupId/artifactId/maven-metadata.xml计算出来的,如:
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus</artifactId>
<versioning>
<latest>1.4.2-SNAPSHOT</latest>
<release>1.4.0</release>
<versions>
<version>1.3.5</version>
<version>1.3.6</version>
<version>1.4.0-SNAPSHOT</version>
<version>1.4.0</version>
<version>1.4.0.1-SNAPSHOT</version>
<version>1.4.1-SNAPSHOT</version>
<version>1.4.2-SNAPSHOT</version>
</versions>
</versioning>
</metadata>
在XML文件列出了仓库中存在的该构件所有可用的版本,同时latest元素指向了这些版本中最新的那个版本。而release元素指向了这些版本中最新的发布版本。Maven通过合并多个远程仓库及本地仓库的元数据,就能计算出基于所有仓库的latest和release分别是什么,然后再解析具体的构件。
需要注意的是,在依赖声明中使用LATEST和RELEASE是不推荐的做法,因为Maven随时都可能解析到不同的构件,可能今天LATEST是1.3.6,明天就成了1.4.0-SNAPSHOT了,且Maven不会明确告诉用户这样的变化。当这种变化造成构建失败的时候,发现问题变得比较困难。RELEASE因为对应的是最新发布版构建,还相对可靠,LATEST就非常不可靠了,为此,Maven3不再支持在插件配置中使用LATEST和RELEASE。如果不设置插件版本,其效果就和RELEASE一样,Maven只会解析最新的发布版本构件。不过即使这样,也还存在潜在的问题。例如,某个依赖的1.1版本与1.2版本可能发布一些接口的变化,从而导致当前Maven构建失败。
当依赖的版本设为快照版本的时候,Maven也需要检查更新,这时,Maven会检查仓库元数据groupId/artifactId/version/maven-metadata.xml,如例:
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>org.sonatype.nexus</groupId>
<artifactId>nexus</artifactId>
<version>1.4.2-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20091214.221414</timestamp>
<buildNumber>13</buildNumber>
</snapshot>
<lastUpdated>20091214221558</lastUpdated>
</versioning>
</metadata>
该xml文件的snapshot元素包含timestamp和buildNumber两个子元素,分别代表了这一快照的时间戳和构建号,基于这两个元素可以得到该仓库中此快照的最新构件版本实际为1.4.2-20091213.221414-13。通过合并所有远程仓库和本地仓库的元数据,Maven就能知道所有仓库中该构件的最新快照。
分享到:
相关推荐
Maven3实战笔记05——仓库依赖解析与插件解析。
Maven3实战
Maven3_04_maven的依赖特性 Maven3_05_maven的聚合和继承 Maven3_06_复习maven的基本内容 Maven3_07_nexus的介绍和安装 Maven3_08_nexus的配置 Maven3_09_发布项目到nexus中 Maven3_10_生命周期和插件简介 Maven3_11...
Maven3实战笔记——03Maven仓库。
Maven3实战笔记 Maven3实战笔记 Maven3实战笔记 Maven3实战笔记
Maven3实战笔记(全) 从安装配置,到仓库依赖,到集成测试,到插件管理,到构建web 作者风趣幽默的介绍了maven3的使用 强烈推荐
Maven3实战笔记(整合)
Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清
Maven3实战笔记08——Maven反应堆。
Maven实战Maven实战Maven的安装、配置及使用入门
Maven实战(基于Maven3).pdf(340页)
kettle是国外开源的一款ETL集成工具,其最新版8.2版本改为了maven项目,由于其maven仓库下载实在太慢,这里提供了我费了一两天才下载好的依赖包,直接解压放在本地仓库即可。方便好使,好用的给个五星好评。
springboot 的maven依赖包,含有所有maven依赖,网络不好的可以来下。压缩包3.
Maven3实战笔记10——使用Maven进行测试。
Maven3实战笔记07——继承的介绍。
Maven3实战笔记04——Maven的生命周期和插件。
Maven3实战笔记06——聚合的介绍。
阿里云云效 是企业级一站式 DevOps 平台,覆盖产品从需求到运营的研发全生命周期,其中云效也提供了免费、可靠的Maven私有仓库 Packages 和代码管理仓库 Codeup,欢迎您体验使用。 云效制品仓库 Packages 致力于帮助...
Maven3实战笔记
nexus 搭建 maven仓库nexus 搭建 maven仓库nexus 搭建 maven仓库nexus 搭建 maven仓库nexus 搭建 maven仓库