Mavenx学习笔记二十二:Maven仓库(从仓库解析依赖的机制)分析

无情 阅读:232 2021-03-31 23:09:34 评论:0


Maven仓库(从仓库解析依赖的机制)

----------

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就能知道所有仓库中该构件的最新快照。 

 

声明

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

发表评论
搜索
KIKK导航

KIKK导航

排行榜
关注我们

一个IT知识分享的公众号