长期读者，第一次问...
我有一个独立的网络（无法访问互联网）。它有一个具有虚拟libs-snapshot和libs-release存储库的工件服务器。在libs-snapshot下，有 4 个本地快照存储库。这样做的原因是我们从其他地方（未连接）获得了所有人工仓库的转储，并将其导入到这个网络。但是我们必须在那里修改快照工件的一个子集。所以我们创建了另一个本地快照仓库，称之为mine-snapshot-local (maven 2 repo, set as unique, max artifacts=1?)，并将其添加到libs-snapshot的顶部虚拟的。从理论上讲，这将允许我们修改我们需要的少量工件，部署到我们自己的存储库，本地开发人员会选择这些。但是我们仍然可以从其他非连接系统的定期转储中访问 99% 的其他工件。此外，我们可以从其他网络批量导入同时修改的 drop，而无需接触我们的独立网络存储库（mine-snapshot-local）。我想我们正在“分支”神器回购......
我意识到我们可能可以直接部署到一个导入的存储库中，但是下次我们从另一个网络获得转储时，所有那些自定义修改的工件都会消失......所以我真的很想用这个方法来如果可能的话工作。
从我的本地 Eclipse 中，maven 插件将工件显式且无错误地部署到mine-snapshot-local存储库。我看到的问题是虚拟 libs-snapshot 的 maven-metadata.xml 没有更新。该文件的时间戳已更新，如果我使用 Web 浏览器浏览 libs-snapshot/whatever_package，我可以看到我新部署的工件，其时间戳比现有快照更新。但是 maven-metadata.xml 文件仍然包含指向“旧”快照的指针。
maven-metadata.xml 在mine-snapshot-local存储库中成功更新，但好像 artifactory 没有为虚拟存储库正确地将所有元数据文件合并在一起。或者，更有可能的是，我错误地配置了一些东西，导致它以某种方式忽略我们的顶层本地 repo（但为什么快照 jar/pom 仍然出现在那里？）。
我们使用的是 artifactory 2.6.1（并且没有升级选项）。
我尝试了很多事情：将快照存储库设置为唯一、非唯一、部署程序、限制快照数量等。这些似乎都没有太大区别。
我认为可能是一个问题的一件事是分配给快照的内部版本号。例如，在导入的仓库中，工件可能有一个一周前的时间戳，但内部版本号为 4355。在我的新仓库中，当我部署时，我有一个更新的时间戳，但内部版本号是 1（或比 4355 小得多的东西）。
我是否通过尝试拥有多个这样的本地快照存储库来找出错误的树？看起来这应该没问题，但也许不是。