maven找不到我当地的文物

Question

我似乎无法逃避,mvn -o package因为它抱怨

存储库系统处于脱机状态,但工件com.liferay.portal:util-bridges:jar:6.1.20在本地存储库中不可用.

但我检查了我的本地存储库,那里存在工件.我也尝试过将updatePolicy设置为从不在settings.xml文件中但是无效的解决方案.

Answer 1

在Maven 3.0.x之前,Maven没有跟踪本地存储库中文件的来源.

这可能会导致构建问题,特别是如果你正在构建一些列出(现已死)非常borked 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日),第4次尝试削减符合法律和测试要求的版本正在进行中...所以,假设第4次是幸运的,我希望看到3.1.0-alpha -1在3-4天内发布...但是它可能会更长,因为我们想要给3.1中的更改​​足够的时间来浸泡以确保使用构建不会中断(API暴露的变化(通过事故是什么 - 插件作者依赖的网站和依赖插件所需的API(尽管他们不应该这样)所以有潜力,尽管我们认为我们已经覆盖了所有的基础)

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

Answer 2

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

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