当 Maven 因找不到某个内部依赖（如 com.x.y）而构建失败时，可通过本地伪造该依赖并结合 mvn dependency:tree 完整解析依赖树，从而精准定位其在哪个 POM 中被间接引入。

当 maven 因找不到某个内部依赖（如 `com.x.y`）而构建失败时，可通过本地伪造该依赖并结合 `mvn dependency:tree` 完整解析依赖树，从而精准定位其在哪个 pom 中被间接引入。

在企业级 Java 项目中，内部依赖（如 com.x.y:artifact-id:1.2.3）通常托管于私有 Artifactory 仓库。若某版本缺失导致构建中断（报错类似 Could not find artifact com.x.y:...），而常规排查（全局 grep、逐个检查 POM、dependency:analyze）均未发现显式声明，说明该依赖极可能来自传递性依赖——即由其他已声明的依赖间接引入。

此时，mvn dependency:tree 是最权威的诊断工具，但它默认会在解析过程中尝试下载所有依赖，一旦遇到缺失的 com.x.y 就会提前失败，无法输出完整树形结构。关键破局点在于：绕过远程下载，让 Maven 能“看到”该坐标并继续解析。

✅ 推荐解决方案：本地伪造依赖（Mock Artifact）

1. 创建占位 JAR 文件
   使用任意工具（如 jar -cf 或空 ZIP 重命名为 .jar）生成一个空的 JAR，确保文件名符合 Maven 坐标规范：

   mkdir -p ~/.m2/repository/com/x/y/artifact-id/1.2.3
   touch dummy.jar
   jar -cf ~/.m2/repository/com/x/y/artifact-id/1.2.3/artifact-id-1.2.3.jar dummy.jar

2. 生成对应的 pom.xml（必需）
   在同一目录下创建 artifact-id-1.2.3.pom，内容至少包含基本坐标声明：

   <?xml version="1.0" encoding="UTF-8"?>
   <project xmlns="http://maven.apache.org/POM/4.0.0">
     <modelVersion>4.0.0</modelVersion>
     <groupId>com.x.y</groupId>
     <artifactId>artifact-id</artifactId>
     <version>1.2.3</version>
   </project>

3. 执行依赖树分析
   此时再运行：

   mvn dependency:tree -Dincludes=com.x.y

   Maven 将从本地 .m2 读取伪造的依赖，成功完成解析，并清晰显示该依赖的完整传递路径，例如：

   

   Java Maven Common

   Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

   下载

   [INFO] \- org.example:parent-lib:jar:2.5.0:compile
   [INFO]    \- com.x.y:artifact-id:jar:1.2.3:compile

   这表明 com.x.y:artifact-id:1.2.3 实际由 org.example:parent-lib:2.5.0 引入。

⚠️ 注意事项：

• 伪造的依赖仅用于诊断，切勿提交到团队仓库或用于实际构建；
• 若项目启用 maven.enforcer.plugin 的 requireUpperBoundDeps 等规则，可能仍会校验失败，可临时禁用或添加 -Denforcer.skip=true；
• 对于多模块项目，需在根目录执行 dependency:tree，或指定 -pl 参数聚焦子模块；
• 更彻底的方案是配置 Maven 使用 --offline 模式 + 本地仓库快照，但伪造法更轻量、普适性强。

总结：当 dependency:tree 因缺失依赖而中断时，本地注入占位 artifact 是高效定位传递源的黄金实践。它不修改项目代码，不依赖网络，直接暴露依赖链路本质——这正是 Maven 依赖解析机制的底层逻辑所决定的可靠路径。