如何为Maven依赖配置import与provided作用域，解决动态加载依赖缺失问题

这个场景我在跨团队协作的项目里遇到过好几次，核心矛盾就是既要避免把Y的JAR打包进X的fat jar，又要保证运行时Y的依赖能被正确加载。下面分方案和Y是否该做fat jar两个部分来聊：

一、最佳依赖管理方案 #

根据不同的团队协作条件，有几种可行的方案：

1. 让Y团队提供带依赖的Shaded Fat Jar #

这是最省心的方案，让Y用maven-shade-plugin打包成一个包含自身所有依赖的fat jar，并且对依赖包进行**重命名（relocate）**处理。这样做的好处是：

• X运行时只需要加载这一个Y的fat jar，不需要额外处理Y的依赖，从根本上解决NoClassDefFoundError
• 重命名可以避免Y的依赖和X的依赖出现版本冲突（比如Y用了Guava 28，X用了Guava 30，重命名后两个版本不会互相干扰）

你只需要在X的pom里保持Y的provided作用域，运行时把这个fat jar放到配置的路径即可。

2. 显式引入Y的依赖并排除出X的Fat Jar #

如果Y团队无法提供fat jar，那可以让他们把Y的pom发布到你们的私有仓库，然后在X的pom里做三件事：

• 保持Y的依赖为provided作用域
• 把Y的所有依赖以runtime作用域引入到X中
• 配置X的fat jar打包插件（比如maven-assembly-plugin或spring-boot-maven-plugin），排除这些Y的依赖，避免被打包进X的jar

这种方式的缺点是需要维护Y的依赖版本，如果Y更新了依赖，X也要同步调整，比较繁琐。

3. 自定义类加载器加载Y及其依赖 #

如果你们的动态加载需求比较复杂（比如需要热更新Y的版本），可以写一个自定义类加载器，在X中指定Y的jar路径和Y的依赖jar路径，让类加载器优先加载这些外部JAR。这种方式灵活性最高，但需要额外开发和维护类加载逻辑，还要处理类加载隔离的问题，适合有一定技术储备的团队。

二、Y是否应该做成Fat Jar？ #

答案是看场景决定：

• ✅ 适合做Fat Jar的情况：Y是独立的业务组件，依赖不多，或者和X的依赖冲突风险高；跨团队协作时，不想让X团队维护Y的依赖
• ❌ 不适合做Fat Jar的情况：Y是被多个项目依赖的通用工具库，做成fat jar会导致依赖重复打包，增加整体包体积；Y的依赖和X的核心依赖完全一致，不需要隔离

额外提醒 #

不管用哪种方案，都要在X的pom.xml里用<dependencyManagement>统一管理Y的版本，避免出现版本不一致的问题；另外，运行时要确保Y的jar（及其依赖）的路径配置正确，并且有读取权限。

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