长期读者，第一次问问...
我有一个独立的网络（没有互联网接入）。它有一个神器服务器，它有虚拟 libs-snapshot 和 libs-release repos。在 libs-snapshot 下，有4个本地快照存储库。这样做的原因是我们从其他地方（非连接）获取所有神器回购的转储，并将其导入该网络。但我们必须修改那里的快照工件的子集。所以我们创建了另一个本地快照仓库，称之为 mine-snapshot-local （maven 2 repo，设置为唯一，max artifacts = 1？），并将其添加到 libs的顶部-snapshot 虚拟。从理论上讲，这将允许我们修改我们需要的少量工件，部署到我们自己的仓库，本地开发人员会选择那些。但是我们仍然可以从其他非连接系统的定期转储中访问99％的其他工件。此外，我们可以批量导入来自其他同时被修改的网络中的drop，而无需触及我们的独立网络仓库（ mine-snapshot-local ）。我想我们已经分享了＃34;神器回购...
我意识到我们可能只是直接部署到其中一个导入的存储库中，但是下次我们从其他网络获取转储时，所有这些自定义修改的工件都会消失......所以我真的很喜欢如果可能的话，让这个方法起作用。
来自我的本地eclipse，maven插件显式地将工件部署到 mine-snapshot-local repo，并且没有错误。我看到的问题是虚拟libs-snapshot的maven-metadata.xml没有被更新。该文件的时间戳已更新，如果我使用Web浏览器浏览libs-snapshot / whatever_package，我可以看到新部署的工件，其时间戳比现有快照更新。但是maven-metadata.xml文件仍然包含指向＆＃34; old＆＃34;快照。
maven-metadata.xml在 mine-snapshot-local repo中成功更新，但就好像artifactory没有正确地将所有元数据文件合并到虚拟仓库中。或者，更有可能的是，我错误配置了某些东西导致它忽略了我们的顶层本地仓库（但为什么快照jar / pom仍会显示在那里？）。我们正在使用artifactory 2.6.1（并且没有升级选项）。
我尝试了很多方面：将快照回购设置为唯一的，非独特的部署，限制快照的数量等等。似乎没有任何差别。
我认为可能存在的一个问题是分配给快照的内部版本号。例如，在导入的repo中，工件的时间戳可能是一周，但是内部版本号为4355.在我的新repo中，当我部署时，我有一个更新的时间戳，但内部版本号为1（或比4355小得多的东西。
我试图拥有这样的多个本地快照存储库，从而咆哮错误的树吗？看起来这应该没问题，但也许不行。
答案 0 :(得分：0)
你正在使用一个非常（但非常）旧版本的Artifactory，这可能是你遇到了一个早已不复存在的问题。正常行为应该是，如果您有4个maven存储库并且您将新工件更新/部署到其中一个存储库中，则虚拟存储库应聚合来自所有列出的存储库的元数据。
只是为了验证，你提到你是从Eclipse部署的，你指的是P2吗？如果只是旁注，Artifactory将不会计算P2工件的元数据。