Maven 官方明确禁止在 pom.xml 中嵌入仓库登录凭证，因存在严重安全风险；所有认证信息必须通过 settings.xml 的 配置管理，这是唯一合规、安全且被 Maven 核心机制支持的方式。
maven 官方明确禁止在 `pom.xml` 中嵌入仓库登录凭证，因存在严重安全风险；所有认证信息必须通过 `settings.xml` 的 `
在 Maven 的设计哲学中，pom.xml 是声明式项目元数据文件——它定义“构建什么”（依赖、插件、生命周期），而非“如何安全地访问资源”。而认证凭据属于敏感运行时配置，其管理职责被严格限定在用户级或全局 settings.xml 中，原因如下：
✅ 安全性强制要求
Maven 文档 Guide to Deployment and Security Settings 明确指出：
"Never put passwords in your POM. Always use the settings.xml file for credentials."
将密码硬编码在pom.xml中会导致：
- 代码仓库泄露即等同于私有仓库凭据泄露；
- Git 历史不可逆，即使删除也无法彻底清除凭据；
- CI/CD 流水线（如 Azure DevOps）若直接提交含密码的 POM，将违反企业安全审计红线。
✅ Maven 认证机制不支持 POM 级凭据解析
Maven 在解析 pom.xml 中的 <repository></repository> 时，完全忽略 <username></username> / <password></password> 等子元素（即使手动添加也无效）。它仅依据 <id></id> 字段，在 settings.xml 的 <servers></servers> 节点中查找匹配的 <server></server> 条目，并提取其中的认证信息。你的当前 POM 中定义的 <custom-repo-username></custom-repo-username> 和 <custom-repo-password></custom-repo-password> 属性，虽可被 Maven 解析为变量，但不会被自动注入到仓库认证流程中——这属于常见误解。
✅ 正确且推荐的解决方案（适用于 Azure DevOps）
无需等待完整 settings.xml 部署，可快速实现安全集成：
-
在
settings.xml中配置服务器凭据（最小化改动）
在 Azure DevOps Pipeline 的maven任务中，通过settingsXml参数指定内联 XML 或文件路径。例如，使用 内联 settings.xml（推荐用于临时调试）：- task: Maven@4 inputs: mavenPomFile: 'pom.xml' mavenOptions: '-Xmx3072m' javaHomeOption: 'JDKVersion' jdkVersionOption: '1.17' jdkArchitectureOption: 'x64' goals: 'clean package' # ? 内联安全配置，凭据通过 Pipeline 变量注入（加密） settingsXml: | <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>custom-repo</id> <username>${env.CUSTOM_REPO_USERNAME}</username> <password>${env.CUSTOM_REPO_PASSWORD}</password> </server> </servers> </settings> # ? 通过 Pipeline 变量传入（需在 Variables 中设为 secret） mavenAuthenticateFeed: false # 关闭自动认证，使用自定义 settings? 注意：
CUSTOM_REPO_USERNAME和CUSTOM_REPO_PASSWORD应在 Azure DevOps Pipeline Variables 中定义为 secret 类型，确保不被日志打印。 保持 POM 清洁，仅声明仓库 ID
你当前的pom.xml中<repository><id>custom-repo</id></repository>已完全正确——只需确保该id与settings.xml中<server><id></id></server>严格一致（大小写敏感），Maven 即可自动绑定凭据。-
验证是否生效
运行以下命令检查认证是否成功：mvn help:effective-settings -Dverbose # 查看输出中是否包含已解析的 <server> 条目 mvn dependency:get -Dartifact=io.smkfdk7.commons:commons-utils:1.3.0 -Dtransitive=false
⚠️ 重要提醒：
- 若强行在
pom.xml中添加<username></username>/<password></password>（非标准写法），Maven 将静默忽略，错误仍会表现为Could not transfer metadata...——这正是你当前遇到的问题根源。 - 私有仓库（如 Artifactory）返回
401 Unauthorized时，Maven 日志通常会提示Failed to retrieve remote metadata，而非明确说“认证失败”，需结合mvn -X调试日志确认。
总结：安全不是可选项，而是 Maven 架构的基石。与其尝试绕过设计约束，不如采用上述轻量、合规、CI 友好的 settings.xml 注入方案——它既满足 Azure DevOps 快速落地需求，又符合企业级安全治理规范。
