Maven 从仓库解析依赖的机制

2018-06-23  本文已影响39人  杰哥长得帅

当本地仓库没有依赖构件的时候，Maven 会自动从远程仓库下载；当依赖版本为快照版本的时候，Maven 会自动找到最新的快照。这背后的依赖解析机制可以概括如下：

  1. 当依赖的范围是 system 时，Maven 直接从本地文件系统解析构件

  2. 根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件则解析成功

  3. 在本地仓库不存在相应构件的情况下，如果依赖的版本显示的发布版本构件，如 1.2、2.1-beta-1 等，则遍历所有的远程仓库，发现后下载并解析使用

  4. 如果依赖的版本是 RELEASE 或者 LATEST，则基于更新策略读取所有远程仓库的元数据 groupId/artifactId/maven-metadata.xml，将其与本地仓库对应元数据合并后计算出 RELEASE 或者 LATEST 真实的值，然后基于这个真实的值检查本地和远程仓库如步骤 2 和 3

  5. 如果依赖的版本是 SNAPSHOT，则基于更新策略读取所有远程仓库的元数据 groupId/artifactId/version/maven-metadata.xml，将其与本地仓库对应元数据合并后得到最新快照版本的值，然后基于该值检查本地仓库或者从远程仓库下载

  6. 如果最后解析得到的构件版本时间是时间戳格式的快照，如 1.4.1-20091104.121450-121，则复制其时间戳格式的文件至非时间戳格式，如 SNAPSHOT，并使用该非时间戳格式的构件

当依赖版本不明晰的时候，如 RELEASE、LATEST 和 SNAPSHOT，Maven 就需要基于更新远程仓库的更新策略来检查更新。有一些配置与此有关：首先是 <releases><enabled> 和 <snapshots><enabled>，只有仓库开启了对于发布版本的支持时，才能访问该仓库的发布版本构件信息，对于快照版本也是同理；其次要注意的是 <release> 和 <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 元素指向了这些版本中最新的那个版本，该例中是 1.4.2-SNAPSHOT。而 release 元素指向了这些版本中最新的发布版本，该例中是 1.4.0。Maven 通过合并多个远程仓库及本地仓库的元数据，就能计算出基于所有仓库的 latest 和 release 分别是什么，然后再解析具体的构件

需要注意的是，在依赖声明中使用 LATEST 和 RELEASE 是不推荐的做法，因为 Maven 随时都可能解析到不同的构件，可能今天 LATEST 是 1.3.6，明天就成了 1.4.0-SNAPSHOT 了，且 Maven 不会明确告诉用户这样的变化。当这种变化造成构建失败的时候，发现问题变得比较困难。RELEASE 因为对应的是最新发布版构建，还相对可靠，LATEST 就非常不可靠了，为此，Maven 3 不再支持在插件配置中使用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 就能知道所有仓库中该构件的最新快照

上一篇下一篇

猜你喜欢

热点阅读