maven依赖下载失败原因分析；_remote.repositories简述

本文主要是介绍maven依赖下载失败原因分析；_remote.repositories简述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

概述

我的maven版本3.6.3

有时在下载maven依赖时，提示某个仓库中没有对应依赖，此时去提示的仓库上找，的确没有，那么通常会加入mirror拦截一下依赖请求，指向到mirrot中的仓库，但是此时仍提示相同的错误。
更奇怪的是，即使此时本地仓库中有依赖，但还是提示某个仓库地址上依赖不存在。

查了一通，资料，到对应依赖下把_remote.repositories文件删除，重新下载依赖就ok了。

附上一个相同问题的Stack Overflow连接
https://stackoverflow.com/questions/16866978/maven-cant-find-my-local-artifacts

_remote.repositories

大致就是说_remote.repositories这个文件是为了标识依赖的来源，需要保证这个来源中依赖一定存在。

这个文件内容大概如下，>符号后的字符为setting文件中配置的<mirror>标签下的id.
如下demo中我用是mirror是aliyun的这里展示的就是aliyun的
在这里插入图片描述

官方解释

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

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)

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.

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)

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

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…

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!!!

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 {} ;
The side effect is that you loose the protections that Maven 3.0.x is
trying to provide.

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)

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)

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)