我似乎无法运行mvn -o package
,因为它抱怨
存储库系统离线但工件 com.liferay.portal:util-bridges:jar:6.1.20不可用 本地存储库。
但是我检查了我的本地存储库,那里存在工件。我还尝试了将updatePolicy设置为从不在settings.xml文件中但是无法正常工作的解决方案。
答案 0 :(得分:56)
在Maven 3.0.x之前,Maven没有跟踪本地存储库中文件的来源。
这可能会导致构建问题,特别是如果你正在构建列出(现在已经死亡)非常borked java.net2存储库的东西......不仅该存储库更改了已发布的工件(非常糟糕和邪恶的做法),但它也在与中心的工件相同的坐标处发布的工件,但具有不同的内容(令人难以置信的邪恶)
所以你可以让构建工作(因为你有commons-io:commons-io:2.0来自中央)擦除你的本地仓库并且构建失败(因为你现在得到了commons-io:commons-io:2.0来自java .net2这是一个完全不同的工件,在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次幸运,我会希望< / em>看3-4.0时间内发布的3.1.0-alpha-1 ...但是它可能会更长,因为我们想要给3.1中的更改足够的时间来浸泡以确保使用构建不会中断(虽然我们认为我们有一个API暴露的API(通过偶然的方式 - 网站和依赖插件需要API),插件作者依赖它(即使它们不应该有)所以有潜力涵盖的所有基地)
希望能回答你的问题(也许还有一些你不知道的问题;-))
答案 1 :(得分:20)
我还必须以与上述_maven.repositories相同的方式删除_remote.repositories。我正在使用Maven 3.1.1
find ~/.m2/repository -name _remote.repositories -exec rm -v {} \;
答案 2 :(得分:0)
当我使用apache-maven-3.0.4时,我遇到了这个问题,在我转移到apache-maven-3.3.1后问题就出现了。
答案 3 :(得分:0)
当我通过shell脚本安装本地工件时,我在Ubuntu Linux中遇到了这个问题。解决方案是删除本地工件并“手动”再次安装它们 - 通过终端调用mvn install:install-file
。