41

我似乎无法跑步mvn -o package，因为它抱怨

存储库系统已离线，但工件 com.liferay.portal:util-bridges:jar:6.1.20 在本地存储库中不可用。

但是我检查了我的本地存储库，并且那里确实存在该工件。我还尝试了在 settings.xml 文件中将 updatePolicy 设置为 never 的解决方案，但未能奏效。

4

4 回答 4

82

在 Maven 3.0.x 之前，Maven 不跟踪本地存储库中文件的来源。

这可能会导致构建问题，特别是如果您正在构建列出（现在已死）非常无聊的 java.net2 存储库的东西......该存储库不仅更改了发布的工件（非常糟糕和邪恶的做法），而且它还在以下位置发布了工件与中央工件的坐标相同但内容不同（令人难以置信的邪恶）

所以你可以让构建工作（因为你有来自中央的 commons-io:commons-io:2.0）擦除你的本地仓库并且构建失败（因为你现在从 java.net2 获得 commons-io:commons-io:2.0是完全不同的工件，在 pom 中有不同的依赖项），反之亦然。

上述情况是使用 maven 存储库管理器的驱动因素之一，因为它允许您控制您在下游公开的存储库子集以及从多个存储库解析工件的顺序（通常称为路由规则）

无论如何，当 maven 切换到 Aether 作为存储库访问层时，决定开始跟踪工件的来源。

因此，对于 Maven 3.0.x，当从存储库下载工件时，maven 会留下一个_maven.repositories文件来记录文件的解析位置。如果您正在构建一个项目，并且存储库的有效列表不包括从中解析工件的位置，那么 Maven 会认为工件不在缓存中，并将寻求重新解析工件。 ..

虽然 3.0.x 中存在许多错误......最关键的是如何offline处理......即：离线时，maven 3.0.x 认为没有存储库，所以总是会发现_maven.repositories文件不匹配！ ！

Maven 3.0.x 的解决方法是从本地缓存中删除这些文件，例如

$ find ~/.m2/repository -name _maven.repositories -exec rm -v {} \;

副作用是您失去了 Maven 3.0.x 试图提供的保护。

好消息是 Maven 3.1 将有所需的修复（如果我们能够齐心协力并发布一个版本）

在离线模式下使用 Maven 3.1，_maven.repositories文件被（半）忽略，并且还有一个选项可以忽略该文件以进行在线构建（称为遗留模式）

在这个时间点（2013 年 6 月 1 日），第四次尝试削减符合法律和测试要求的版本正在进行中......所以，假设第四次是幸运的，我希望看到 3.1.0-alpha -1 在 3-4 天内发布......但考虑到我们希望给 3.1 中的更改足够的时间来浸泡以确保使用构建不会中断（暴露的 API 发生了变化（通过意外 - 站点和依赖插件需要 API）插件作者依赖（即使他们不应该拥有）所以有潜力，尽管我们认为我们已经涵盖了所有基础）

希望能回答你的问题（也许还有一些你不知道的问题;-)）

于 2013-06-01T08:06:05.153 回答
31

我还必须以与上述 _maven.repositories 相同的方式删除 _remote.repositories。我正在使用 Maven 3.1.1

find ~/.m2/repository -name _remote.repositories -exec rm -v {} \;
于 2014-01-30T23:01:29.647 回答
0

当我通过 shell 脚本安装本地工件时，我在 Ubuntu Linux 中遇到了这个问题。解决方案是删除本地工件并“手动”重新安装它们 -mvn install:install-file通过终端调用。

于 2017-01-16T04:02:40.603 回答
0

我在使用 apache-maven-3.0.4 时遇到了这个问题，在我迁移到 apache-maven-3.3.1 后问题就消失了。

于 2016-04-29T02:09:30.697 回答