Maven找不到我的本地工件 [英] maven can't find my local artifacts

问题描述

我似乎无法运行mvn -o package，因为它抱怨

I can't seem to run mvn -o package because it complains with

存储库系统已脱机，但工件 com.liferay.portal:util-bridges:jar:6.1.20在 本地存储库.

The repository system is off line but the artifact com.liferay.portal:util-bridges:jar:6.1.20 is not available in the local repository.

但是我检查了我的本地存储库，并且那里确实存在工件.我也尝试了将updatePolicy设置为从不在settings.xml文件中但无法正常工作的解决方案.

But I checked my local repository and that artifact does exist there. I also tried the solution of setting updatePolicy to never in the settings.xml file but that failed to work.

推荐答案

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

Prior to Maven 3.0.x, Maven did not track the origin of files in the local repository.

这可能会导致构建问题，特别是如果您正在构建的列表中列出了(现在已经死了)非常乏味的java.net2存储库...不仅该存储库更改了已发布的工件(极端的坏习惯)，而且还更改了发布的文物与中央文物的坐标相同，但内容不同(令人难以置信的邪恶)

This could result in build issues, especially if you were building something that listed the (now dead) very borked java.net2 repository... Not only did that repository change released artifacts (extremely bad and evil practice) but it also published artifacts at the same coordinates as artifacts on central but with different content (unbelievably evil)

因此，您可以进行构建工作(因为您从中央有commons-io:commons-io:2.0)擦除了本地存储库，并且构建失败了(因为您现在从Java获得了commons-io:commons-io:2.0 .net2是完全不同的工件，在pom中有不同的依赖关系，或反之亦然.

So you could have the build work (because you had commons-io:commons-io:2.0 from central) wipe your local repo and the build fails (because you now get commons-io:commons-io:2.0 from java.net2 which was a completely different artifact with different dependencies in the pom) or vice versa.

以上情况是使用Maven存储库管理器的驱动程序之一，因为它使您可以控制向下游公开的存储库的子集以及从多个存储库解析工件的顺序(通常称为路由)规则)

The above situation is one of the drivers for using a maven repository manager, because that allows you to control the subset of a repository that you expose downstream and the order in which artifacts are resolved from multiple repositories (usually referred to as routing rules)

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

In any case, when maven switched to Aether as the repository access layer, the decision was made to start tracking where artifacts come from.

因此，对于Maven 3.0.x，当从存储库下载工件时，maven会留下一个_maven.repositories文件来记录从中解析文件的位置.如果正在构建项目，并且有效的存储库列表不包含解析工件的位置，则Maven会确定该工件好像不在高速缓存中，并将尝试重新解析该工件. ..

So with Maven 3.0.x, when an artifact is downloaded from a repository, maven leaves a _maven.repositories file to record where the file was resolved from. If you are building a project and the effective list of repositories does not include the location that the artifact was resolved from, then Maven decides that it is as if the artifact was not in the cache, and will seek to re-resolve the artifact...

尽管在3.0.x中存在许多错误...最关键的是如何处理offline ...即:当脱机时，maven 3.0.x认为没有存储库，因此将始终找到一个存储库.与_maven.repositories文件不匹配！！

There are a number of bugs in 3.0.x though... The most critical being how offline is handled... Namely: when offline, maven 3.0.x thinks there are no repositories, so will always find a mismatch against the _maven.repositories file!!!

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

The workaround for Maven 3.0.x is to delete these files from your local cache, eg

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

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

The side effect is that you loose the protections that Maven 3.0.x is trying to provide.

好消息是Maven 3.1将具有所需的修复程序(如果我们能够一起行动并发布版本的话)

The good news is that Maven 3.1 will have the required fix (if we can ever get our act together and get a release out the door)

在Maven 3.1处于脱机模式时，_maven.repositories文件被(半)忽略，并且还有一个选项可以忽略该文件以进行在线构建(称为旧版模式)

With Maven 3.1 when in offline mode the _maven.repositories file is (semi-)ignored, and there is also an option to ignore that file for online builds (referred to as legacy mode)

目前(2013年6月1日)正在进行第四次削减符合法律和测试要求的发行版的尝试...因此，假设第四次是幸运的，我会<希望>希望可以看到3.1.0-alpha-1在3-4天的时间内发布了...但是考虑到我们想给3.1中的更改​​留出足够的时间来浸泡以确保使用构建不会中断，它的时间可能会更长(插件作者所依赖的API暴露(偶然的情况-网站和依赖插件需要该API)发生了变化(即使他们不应该这样做)，因此有潜力，尽管我们认为我们有所有基础都包括在内)

At this point in time (June 1st 2013) the 4th attempt to cut a release that meets the legal and testing requirements is in progress... So, assuming that the 4th time is lucky, I would hope to see 3.1.0-alpha-1 released in 3-4 days time... But it could be longer given that we want to give the changes in 3.1 enough time to soak to ensure uses builds don't break (there was a change in an API exposed (by accident-ish - the API is needed by the site and dependency plugin) that plugin authors have depended on (even though they shouldn't have) so there is potential, though we think we have all the bases covered)

希望能回答您的问题(也许还有更多您不知道的问题；-))

Hope that answers your question (and maybe a few more you didn't know you had ;-) )

这篇关于Maven找不到我的本地工件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！