如何修复 Nexus 存储库中不正确的校验和？
我的本地 Nexus 存储库中的某些工件没有正确的校验和。例如（错误的校验和）：
catcentral/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom.sha1 95f3332c2bbace129da501424f297e47dd0e976b
与（正确的校验和）：
sha1sumcentral/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom 4c2947f7e2d09b6e13da34292d897c564f1f9828
看起来我的存储库中有一些工件是在此错误出现时下载的积极的。
Maven Central 现在具有正确的校验和 (4c29...)，但我的本地 Nexus 存储库中的校验和仍然过时。我不知道如何让我的本地存储库来验证和/或从中央重新下载正确的校验和。
修复我的本地存储库的正确方法是什么？没有太多的工件存在这个问题，所以我想我可以（手动）验证它们仍然存在于中央并从我的本地存储库中删除它们。它们应该使用正确的校验和重新缓存。有更好的办法吗？
更新：
我对此进行了更多研究，我几乎确信我知道问题的根源是什么。我遇到麻烦的工件之一就是这个（plexus-compiler-api:1.8< /a>)：
在我的存储库中，.pom 和 .pom.sha1 的时间戳均为 2010 年 3 月 29 日。在中心，.pom 的时间戳为 2010 年 3 月 29 日，而 .pom.sha1 的时间戳为 2010 年 4 月 21 日。我正在阅读有关Nexus 维护的内容。我假设，在 2010 年 4 月 21 日，Maven Central 重建了元数据并验证了校验和，修复了 plexus-compiler-api:1.8 工件的不正确的 .sha1。
根据上面的 Sonatype 链接，我应该能够使 Maven Central 的缓存过期，并让我的本地安装提取具有比原始缓存工件更新的时间戳的任何内容的新副本。但是，根据我观察到的行为，我认为它只是检查工件文件的时间戳，而不是校验和文件。
就我的本地 Nexus 存储库而言，我拥有该工件的最新版本（2010 年 3 月 29 日），因此无需重新下载任何内容。
我注意到我的 Nexus 版本相当旧（1.5 与 1.9.1），因此我将尝试更新并查看新版本是否能更好地处理过期缓存。如果没有，我可能会看看 Sonatype 的人怎么想（也许这是一个错误？）。
Some of the artifacts in my local Nexus repository don't have the correct checksum. For example (wrong checksum):
cat central/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom.sha1
95f3332c2bbace129da501424f297e47dd0e976b
vs (correct checksum):
sha1sum central/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom
4c2947f7e2d09b6e13da34292d897c564f1f9828
It looks like I have a few artifacts in my repository that were downloaded when this bug was active.
Maven Central has the correct checksum (4c29...) now, but the checksums in my local Nexus repository remain stale. I don't know how to get my local repository to verify and / or re-download the correct checksum from central.
What is the correct way of fixing my local repository. There aren't too many artifacts with this problem, so I think I could (by hand) verify they still exist in central and delete them from my local repository. They should get re-cached with the correct checksums. Is there a better way?
Update:
I've looked at this more and I'm almost positive I know what the source of my problem is. One of the artifacts I'm having trouble with is this one (plexus-compiler-api:1.8):
In my repository, both the .pom and .pom.sha1 are timestamped as 29-Mar-2010. At central, the .pom is timestamped as 29-Mar-2010 while the .pom.sha1 is timestamped as 21-Apr-2010. I was reading about Nexus maintenance. I assume that, on 21-Apr-2010, Maven Central rebuilt metadata and verified checksums which fixed the incorrect .sha1 for the plexus-compiler-api:1.8 artifact.
According to the Sonatype link above, I should be able to expire the caches for Maven Central and have my local installation pull new copies of anything with newer timestamps than the originally cached artifacts. However, based on the behavior I've observed, I think it's only checking timestamps for artifact files, not checksum files.
As far as my local Nexus repository is concerned, I have the most recent version of the artifact (29-Mar-2010), so there's no need to re-download anything.
I've noticed my version of Nexus is quite old (1.5 vs 1.9.1), so I'll try updating and see if the newer version does a better job of expiring caches. If not, I'll probably see what the Sonatype guys think (maybe it's a bug?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，你面对的是 Nexus 和 Maven 定义的行为。
首先，过期的缓存不会从 Nexus 的本地缓存中删除任何内容，它只是将它们标记为“旧”。将项目标记为“旧”的效果会在下一个请求相同工件的传入请求中显示（如果从未要求过，“旧”工件就放在那里）。这意味着，单独使缓存过期不会导致 Nexus 下载远程更改（较新）的文件。 Nexus 永远不会自行下载（如果我们在本次讨论中省略索引）。您必须强制客户端（Maven）请求它们——这将导致以下一系列操作：“缓存旧内容”、远程更改检测以及最终重新下载和缓存新文件。
接下来，这里发生的是 Maven，因为工件（JAR 文件）没有更改，甚至也没有要求校验和文件，因此没有任何内容“触发”Nexus 端上“旧”标记的校验和重新获取。其他需要注意的是，如果我们谈论已发布的工件（Maven Central 确实只包含已发布的工件），Maven 将永远不会重新检查它们，除非它们不存在于本地存储库中（一旦引入本地存储库，Maven 将永远不会尝试重新获取）他们）。这意味着，您需要从本地存储库中删除它们，以确保 Maven 会向 Nexus 请求它们，最后，Nexus 将检测远程上的校验和文件更改并执行您真正想要的操作。
应该重新下载，例如，如果您破坏 Maven 的本地存储库并使用干净/空的存储库进行重建。在这种情况下，Maven 应该要求提供 JAR 工件和校验和文件 - 但从您的描述来看，并不清楚您（或者您是否？）在 Nexus 上的缓存过期后如何调用 Maven。
试试这个：
a）在 Nexus“Maven Central”代理存储库上运行过期缓存
b）nuke 本地存储库（或者通过篡改 ~/.m2/settings.xml 将其重定向到新的干净文件夹
c）让 Maven 构建您的项目，然后它应该重新获取 JAR 和校验和文件（通过使用空/无核本地存储库）
希望这可以解释您编写的一些内容。
参考JIRA 问题讨论相同的事情。
Nope, what you face is the defined behaviour of Nexus and Maven.
First, expiring caches does not delete anything from local cache of Nexus, it just marks them "old". The effect of marking items as "old" is shown on next incoming request asking for those same artifacts (if never asked for, the "old" artifacts just sits there). Meaning, expire cache alone will not cause Nexus to download remotely changed (newer) files. Nexus never downloads on it's own (if we leave out the index from this discussion). You have to force a client (Maven) ask for them – and that will result following chain of action: "cache content old", remote change detection and finally re-download and caching of the new file.
Next, what happens here is that Maven, since artifact (the JAR file) is not changed, not even asks for checksum file either, hence nothing "triggers" the "old" marked checksum refetch on Nexus side. Other to note, if we talk about released artifact (and Maven Central does contains released artifacts only), Maven will never re-check them, unless they are not present in local repository (once brought into local repository, Maven will never try to refetch them). Meaning, you need to remove them from local repository to be sure that Maven will ask for them from Nexus, and finally, that Nexus will detect the checksum file changes on remote and do what you actually want.
Re-download should happen, for example if you nuke your Maven's local repository and rebuild with a clean/empty one. In this case, Maven should ask for both, JAR artifact and checksum file – but from your description it's not clear how did you (or did you?) invoke Maven after expiring caches on Nexus.
Try this:
a) run expire caches on Nexus "Maven Central" proxy repository
b) nuke local repository (or just redirect it to a new clean folder by tampering ~/.m2/settings.xml
c) make Maven build your project, and it should refetch both, the JAR and checksum files (by using empty/nuked local repository)
Hope this explains some of the stuff you wrote.
Reference to JIRA issue discussing same thing.
这是一个错误。
正如 Tamas 所解释的，当代理存储库缓存过期时，Nexus 将检查远程存储库是否有较新的时间戳。本地缓存的工件本质上被标记为脏，并且当从本地 Nexus 服务器请求工件时，会根据需要检查更新的工件。
Nexus (1.9.1) 假设如果工件时间戳不变，则校验和也应该不变。大多数情况下这是正确的，但是，由于 Maven 中的旧错误正在部署具有不正确校验和的工件，因此在极少数情况下工件可以保持不变但具有更新的校验和。
我认为目前处理此问题的最佳方法是移动任何错误的校验和，并让 Nexus 在下次请求时尝试重新解析它们：
mv plexus-compiler-api.pom.sha1 plexus-compiler-api- 1.8.pom.sha1.bak
感谢塔马斯的帮助。
This was a bug.
As explained by Tamas, when a proxied repository cache is expired, Nexus will check the remote repository for newer timestamps. The locally cached artifacts are essentially flagged dirty and the check for updated artifacts happens on demand as artifacts are requested from the local Nexus server.
Nexus (1.9.1) is making the assumption that if an artifact timestamp is unchanged, the checksums should be unchanged as well. Most of the time this will be true, but, due to the old bug in Maven that was deploying artifacts with incorrect checksums, there are rare cases where an artifact can be unchanged yet have an updated checksum.
I think the best way to deal with this for now will be to move any bad checksums and let Nexus try to re-resolve them the next time they are requested:
mv plexus-compiler-api.pom.sha1 plexus-compiler-api-1.8.pom.sha1.bak
Thanks for the help Tamas.