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.

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

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 日)第 4 次尝试剪辑符合法律和测试要求的版本正在进行中......所以，假设第 4 次是幸运的，我会希望 看到 3-4 天后发布 3.1.0-alpha-1 ......但考虑到我们希望给 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屋！