Maven 3 依赖解析失败，直到删除 maven-metadata-local.xml 文件 [maven-invoker-plugin 相关]
在我的一个 Maven 项目中，依赖项解析将成功一次，然后在以后的构建尝试中失败：
[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing, no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency information available
……等等，直到我删除 maven-metadata-local.xml与失败工件对应的文件（例如~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml）。删除这些文件后，下一次 mvn 调用将正常进行；元数据文件通过该调用恢复（大概是检查我的上游存储库/镜像是否有更新的工件的过程的一部分），并且我再次出现上述错误，直到我再次删除元数据文件。
这会影响多个项目，尽管它似乎仅限于一组特定的依赖项。我想我可以使用核技术并炸毁我的本地仓库，但我想了解问题是什么。
想法？
更新：它看起来像是 maven-invoker-plugin< /a> （这些构建用于通用集成测试）正在生成这些 maven-metadata-local.xml 文件。我没有使用仅集成测试的本地存储库 如此处所述，仅仅是因为这样做会导致重新下载所有传递依赖项（除非您想维护特定于集成的 settings.xml 文件！ ！）。我已经以这种方式将调用器插件与各种其他项目一起使用，并取得了良好的结果——当然，在这样的过程中从未遇到过楔入的本地存储库。
更新 2 好的，这是可重复的，即使在从全新的本地存储库开始之后也是如此。这是在 OS X、Java 1.6.0_24 和 Maven 3.0.3 上；请注意，Maven 2.2.1 确实不出现此问题。
这是有问题的项目之一：rummage 的 1.3.0-compat 分支。重现：
> mvn clean test
# no error -- can run this and other builds that don't involve maven-invoker-plugin all day w/o problems
> mvn clean integration-test
# FAIL: "Could not resolve dependencies", with warnings as noted above
> mvn clean test
# FAIL: "Could not resolve dependencies", with warnings as noted above
一旦本地存储库被中断（通过生成 maven-metadata-local.xml 文件，AFAICT），任何构建都不会通过依赖关系解析阶段。
运行 mvn -X 会显示每个后来显然找不到的工件的类似行：
[DEBUG] Verifying availability of /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
当然，/Users/chas/.m2/repository/javax/mail/mail/1.4.4 /mail-1.4.4.jar 等。 确实存在，/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom也是如此。完全困惑了。此时，我假设这是 Maven 3（或某些底层库）中的一个错误，现在我看到 2.2.1 是干净的。
更新 3 与 Maven 项目一起提交的错误报告。
In one of my Maven projects, dependency resolution will succeed once, then fail for later build attempts:
[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing, no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency information available
…and so on, until I delete the maven-metadata-local.xml files corresponding to the failing artifacts (e.g. ~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml). After those files are deleted, the next mvn invocation proceeds properly; the metadata files are restored by that invocation (presumably as part of the process of checking my upstream repositories/mirrors for updated artifacts), and I am again presented with the above errors until I again delete the metadata files.
This impacts multiple projects, though it appears to be limited to a particular set of dependencies. I suppose I could go nuclear and blow away my local repo, but I'd like to understand what the problem is.
Thoughts?
Update: It looks like it's the maven-invoker-plugin (which these builds are using for general-purpose integration testing) that is producing these maven-metadata-local.xml files. I'm not using an integration-testing-only local repo as described here, simply because doing so causes the re-downloading of all transitive dependencies (unless you want to maintain an integration-specific settings.xml file!!!). I've used the invoker plugin with a variety of other projects in this way with good results -- certainly never encountering a wedged local repository in the process like this.
Update 2 OK, this is repeatable, even after starting with a completely fresh local repository. This is on OS X, Java 1.6.0_24 with Maven 3.0.3; note that Maven 2.2.1 does NOT exhibit this problem.
Here's one of the projects in question: the 1.3.0-compat branch of rummage. To reproduce:
> mvn clean test
# no error -- can run this and other builds that don't involve maven-invoker-plugin all day w/o problems
> mvn clean integration-test
# FAIL: "Could not resolve dependencies", with warnings as noted above
> mvn clean test
# FAIL: "Could not resolve dependencies", with warnings as noted above
Once the local repository is borked (by the generation of the maven-metadata-local.xml files, AFAICT), no builds will get past the dependency resolution stage.
Running mvn -X reveals lines like this for each artifact that is later apparently not found:
[DEBUG] Verifying availability of /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
Of course, /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar et al. does exist, as does /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom. Totally puzzled. At this point, I'm assuming this is a bug in Maven 3 (or some underlying library), now that I see that 2.2.1 is clean.
Update 3 Bug report filed with Maven project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
此问题在 aether 1.12 中得到解决，该版本比 Maven 3.0.3 附带的 aether 1.11 库高出一版本。在 Maven 安装中用 1.12 替换 aether 1.11 会产生预期的行为（如我提交的错误中所述）。希望 Maven 3.0.4 能尽快与 aether 1.12 一起发布。 :-)
This issue is resolved in aether 1.12, one rev above the aether 1.11 library that ships with Maven 3.0.3. Replacing aether 1.11 with 1.12 in one's Maven install results in expected behaviour (as noted in the bug I filed). Here's hoping Maven 3.0.4 is released with aether 1.12 ASAP. :-)
您没有提及您可能尝试过的内容，所以也许您没有尝试以下这一操作：添加 -U 选项来强制更新？ （也许这个 -U 选项只与快照相关......）
you do not mention what you may have tried, so maybe you didn't try this one: adding the -U option to force update ? (tho maybe this -U option is only relevant for SNAPSHOTs ...)
我见过由本地存储库中损坏的文件引起的类似错误。例如，如果下载中途失败，或者远程存储库中的文件在下载后发生更改。删除
~/.m2下受影响的目录修复了该问题。I've seen similar errors caused by corrupted files in my local repository. For example, if a download failed partway through, or a file in a remote repository changed after I downloaded it. Deleting the affected directories under
~/.m2fixed it.