在与 Maven 存储库管理器交谈时，我不喜欢使用 url 解析器。问题是 Maven 对快照修订有特殊且相当独特的处理...... url 解析器更适合用于 ivy 存储库。
我使用 Nexus，但以下内容也应该适用于 Artifactory。以下设置文件设置 Maven Central 和我的两个托管存储库（Maven 存储库有两种风格，发布或快照）：
<ivysettings>
<settings defaultResolver="repos" />
<resolvers>
<chain name="repos">
<ibiblio name="central" m2compatible="true"/>
<ibiblio name="my-releases" m2compatible="true" root="https://myhost/releases"/>
<ibiblio name="my-snapshots" m2compatible="true" root="https://myhost/snapshots"/>
</chain>
</resolvers>
</ivysettings>
您会注意到我正在使用具有内部逻辑的ibilio解析器来破译 Maven 的特殊快照处理。
当我需要快照修订时，我认为明确声明如下：
<ivy-module version="2.0">
<info organisation="myOrg" module="Demo"/>
<dependencies>
<dependency org="myOrg" name="myModule" rev="2.7-SNAPSHOT"/>
..
</dependencies>
</ivy-module>
在后台， ibilio解析器正在读取 Maven 存储库元数据文件，以确定应该从快照存储库中获取哪个带时间戳的工件。
更新
我建议阅读以下演示文稿：
它很好地概述了将发布与开发构建（或快照）分开的 Maven 哲学。它还解释了 Maven 非常笨拙的方面之一......发布工件的两种不同方式......
我怀疑您正在尝试做的是按照作者的思路，即设置 CD 管道。在这种情况下，每个构建都是一个潜在的版本，应该这样对待（没有快照允许的动态依赖关系）。
我建议将快照限制为仅限开发人员构建。仅部署候选版本。这种方法的问题在于管理大量的发布。一些存储库管理器（Nexus、Artifactory、Archiva）提供“暂存”功能，可以验证或丢弃未通过质量关卡的版本。
更新 2
如果您使用 ivy 将快照发布到 Maven 存储库中，那么有几个问题：
在我看来，时间戳文件首先是使用快照的杀手级功能之一。使用 ivy 只能提供最新的文件（覆盖以前的最新文件）。
有一些变通方法可以解决这些问题：
- 正如第二个链接中所建议的，您可以完全忽略元数据（将“useMavenMetadata”属性设置为false）并默认返回到常春藤比较文件名的旧机制。这只解决了常春藤客户的问题。
- 存储库管理器应该能够重新生成元数据文件（Nexus 至少有一个任务来执行此操作）。
- 使用 Maven ANT 任务。
最后一个建议并不像看起来那么疯狂。首先，这是我知道的唯一支持时间戳快照的方法，其次，Maven 客户端似乎做了很多额外的处理（更新模块元数据），这些处理基本上没有记录。