Maven下载依赖时跳过settings.xml配置仓库的问题排查

从调试日志里的核心输出一眼就能定位问题：

[DEBUG] Verifying availability of ... from [central (..., disabled), artifactory-redhat-ga, artifactory-foo-release (https://artifactory.example.com/artifactory/release, default, releases+snapshots), apache.snapshots]

• 你配置的artifactory-foo-staging、artifactory-foo-external、artifactory-foo-dev三个仓库根本没出现在实际生效的仓库列表里，Maven当然不会往这三个地址发下载请求。
• 生效列表里的artifactory-foo-release仓库地址是https://artifactory.example.com/artifactory/release，和你settings.xml里写的https://artifactory.example.com/artifactory/proj-foo-release完全对不上；列表里还多了个你settings.xml里从来没定义过的apache.snapshots仓库。
• 生效列表里标注artifactory-foo-release同时启用了releases和snapshots拉取，和你settings里给这个仓库配的snapshots.enabled=false完全矛盾。

这三点实锤：你settings.xml里central profile配的仓库根本没生效，这次构建用的仓库列表全是从项目POM（包括继承的父POM）里读的，而POM里配的仓库恰好没包含你要的staging等三个仓库，Maven只会挨个跑POM里列的仓库找依赖，当然找不到存在staging仓库里的构件。

最常见的导致settings里profile失效的原因就是profile ID重名：你给settings里的profile起的ID是central，如果项目POM（或父POM）里恰好也有个ID叫central的profile，Maven会优先用POM里的配置，直接把settings里的同名profile覆盖掉。
其他可能的原因还有：

• settings.xml存在XML语法错误（比如标签没闭合、缩进乱了导致标签嵌套错误），部分配置没被Maven解析到，不过这种情况一般Maven启动时就会抛配置解析错误，很容易发现。
• 全局Maven配置（$M2_HOME/conf/settings.xml）里有同名profile或者镜像规则，覆盖了用户目录下的settings配置。

另外你配置里还有个隐性问题：artifactory-redhat-ga对应的server节点没配用户名密码，如果这个仓库需要认证，后面就算仓库进了生效列表也会报401权限错误。
你之前给三个staging/external/dev仓库配的updatePolicy=never不是这次问题的原因——这个配置只会让Maven在本地已有构件缓存时不检查更新，本地完全没有构件的时候还是会发起请求，而且如果是这个原因，仓库本身还是会出现在生效列表里，和你现在的现象不符。

三个方法，准确度从高到低：

1. 输出有效POM（最准确）
   执行下面的命令：

   mvn help:effective-pom -Doutput=effective-pom.xml
   

   生成的effective-pom.xml里的<repositories>和<pluginRepositories>节点，就是Maven构建时实际用的所有普通依赖仓库、插件仓库，是所有配置（POM继承、settings、默认超级POM）合并后的最终结果，没有任何偏差。
2. 输出有效settings配置
   执行命令：

   mvn help:effective-settings -Doutput=effective-settings.xml
   

   生成的文件里能看到所有被Maven正确解析、激活的profile，以及profile里配的仓库、凭证信息，可以先用来确认你写的settings配置是不是真的被Maven识别到了。
3. 从debug日志直接提取
   你加-X参数打印的调试日志里，搜Verifying availability of关键字，后面中括号里列的就是当前依赖解析时Maven会挨个轮询的所有仓库，不在这个列表里的仓库，Maven绝对不会发请求。

如果暂时没权限修改项目父POM的仓库配置，别用central当settings里的profile ID，换个不会重名的ID（比如custom-internal-repos），把那几个内部仓库配置挪到这个新profile里，再执行mvn clean install -U -Pcustom-internal-repos构建就行，避免和POM里的同名profile冲突。

内容的提问来源于stack exchange，提问作者WesternGun