Maven传递依赖兼容问题：含排除与无排除的Ext1依赖冲突

依赖层级结构 #

LibModel
+ Ext1
   - exclude(ext2)
LibApp
+ LibModel
+ Ext1 --- 显式添加未排除Ext2
   + ext2

问题现象 #

• 仅依赖LibApp的项目：可间接引入LibModel、Ext1及Ext2，运行正常
• 同时显式依赖LibModel和LibApp的项目：依赖树中缺失Ext2，导致运行异常；移除LibModel的直接依赖后，Ext2重新出现在依赖树中

问题根源 #

Maven的依赖调解机制中，当同一依赖（如Ext1）通过多个路径被引入时，若其中一条路径带有排除规则（如LibModel对Ext1排除Ext2），该排除规则会被应用到整个依赖树的对应依赖上。当项目直接依赖LibModel时，Ext1的排除规则会覆盖LibApp中对Ext1无排除的声明，最终导致Ext2无法被引入。

可行解决方案 #

方案1：在LibApp中显式引入Ext2 #

在LibApp的pom.xml中直接添加Ext2的依赖，利用直接依赖的优先级高于间接依赖排除规则的特性，确保无论其他依赖路径如何，Ext2都会被引入：

<dependency>
    <groupId>[ext2的groupId]</groupId>
    <artifactId>[ext2的artifactId]</artifactId>
    <version>[与Ext1依赖的Ext2版本保持一致]</version>
    <scope>compile</scope>
</dependency>

方案2：在LibApp中重声明Ext1并固化依赖 #

在LibApp依赖Ext1时，显式指定版本且不添加排除规则，借助Maven的依赖路径优先级（当两条路径长度相同时，优先选择显式指定版本的依赖），覆盖LibModel中对Ext1的排除规则：

<dependency>
    <groupId>[ext1的groupId]</groupId>
    <artifactId>[ext1的artifactId]</artifactId>
    <version>[明确指定对应版本]</version>
    <!-- 不设置exclusions节点，即保留Ext2的传递依赖 -->
</dependency>

方案3：调整LibModel的依赖范围 #

若LibModel仅需Ext1的编译期类定义、无需其传递依赖，可将LibModel中Ext1的依赖范围设为provided，让下游项目自行管理Ext1的依赖传递，但此方案会增加下游项目的配置成本：

<dependency>
    <groupId>[ext1的groupId]</groupId>
    <artifactId>[ext1的artifactId]</artifactId>
    <version>[对应版本]</version>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>[ext2的groupId]</groupId>
            <artifactId>[ext2的artifactId]</artifactId>
        </exclusion>
    </exclusions>
</dependency>

背景说明 #

• 仅维护LibModel和LibApp，无法修改Ext1/2的依赖配置
• Ext2为Spring核心库，包含部署运行必需的自动配置逻辑，编译测试阶段无感知但运行时不可缺失
• LibModel为轻量级模型工具库，仅需Ext1的类定义，因此排除Ext2以精简依赖；LibApp为应用级库，需要完整的Ext1依赖（含Ext2）

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