Maven基础：添加新依赖为何会导致类找不到？

这种情况本质是Maven依赖传递机制中的规则触发了依赖变更，常见原因有以下几种：

1. 依赖调解导致第三方库版本被替换 #

Maven的依赖调解遵循「路径最短优先」「同路径下声明顺序优先」的规则。假设之前模块C通过模块B间接依赖了包含SomeClass的第三方库新版本，而你新增的模块A依赖了不含该类的旧版本。当模块B引入模块A后，模块C对第三方库的依赖路径变成了C -> B -> A -> 旧版库，这条路径比原来的C -> B -> 新版库更短，Maven会优先选择旧版库，自然找不到目标类。

2. 依赖范围限制导致依赖无法传递 #

如果模块B原本依赖第三方库的范围是compile（默认，可传递到编译期），但模块A中该第三方库的依赖范围是provided或test：

• provided表示依赖由容器提供，不会传递到下游模块的编译类路径
• test仅用于测试阶段，同样不会传递到编译期
  当模块B引入模块A后，Maven会继承更严格的依赖范围，导致模块C在编译时无法获取到该第三方库。

3. 依赖排除规则被传递 #

模块A的pom.xml中可能对该第三方库配置了<exclusions>，强制排除了这个依赖。当模块B依赖模块A时，这个排除规则会被传递给模块C，直接导致第三方库从模块C的类路径中消失。

解决方法 #

• 排查依赖树：在项目根目录执行命令：

  mvn dependency:tree -pl 模块C -Dverbose
  

  查看输出中该第三方库的最终来源，确认是哪个依赖导致了版本替换或排除。
• 显式声明依赖：在模块C的pom.xml中直接添加该第三方库的正确版本依赖，强制Maven使用这个版本，覆盖传递过来的依赖：

  <dependency>
      <groupId>some.third.party</groupId>
      <artifactId>lib</artifactId>
      <version>正确版本号</version>
  </dependency>
  

• 调整依赖范围或排除规则：
  • 检查模块A中第三方库的依赖范围，若无需provided/test，改为compile；
  • 若模块A的排除规则是不必要的，在模块B依赖模块A时，通过<exclusions>反向排除该规则：

    <dependency>
        <groupId>你的groupId</groupId>
        <artifactId>模块A</artifactId>
        <exclusions>
            <exclusion>
                <groupId>some.third.party</groupId>
                <artifactId>lib</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    

  之后再在模块B中重新引入正确的第三方库依赖。

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