Maven构建uber jar包时依赖管理的冗余问题咨询

同版本重复依赖的打包逻辑 #

Maven的依赖解析机制会基于groupId:artifactId:version（简称GAV）唯一标识一个依赖，只要两个依赖的GAV完全一致，不管是直接依赖还是传递引入的间接依赖，Maven只会将该依赖解析一次。
在构建uber jar时，无论是使用maven-assembly-plugin还是maven-shade-plugin，默认都会基于已去重的依赖列表打包，所以你提到的应用A和组件foo同时引入同版本bar的场景，最终产物里只会保留一份bar的副本，不会重复打包。

maven-shade插件混淆场景的处理逻辑 #

maven-shade的类重命名（也就是你提到的混淆能力）是在依赖解析完成后才执行的后置步骤，依赖去重逻辑在解析阶段就已经完成，所以混淆处理阶段也只会对唯一的bar依赖做一次重命名操作，不会额外生成冗余副本。
只有当你主动配置了重复的依赖包含规则、或者同一个依赖存在多个不同版本时，才可能出现重复打包的情况，和shade的混淆能力无关。

行业通用的依赖冗余规避方案 #

• 统一管理依赖版本：在父POM的dependencyManagement节点声明所有内部、第三方依赖的版本，子模块引入依赖时无需声明版本，从根源避免同一个依赖多版本共存导致的冗余和冲突。
• 开启打包瘦身配置：使用maven-shade-plugin时可配置<minimizeJar>true</minimizeJar>，插件会自动扫描字节码引用关系，移除所有未被实际调用的类，大幅降低jar包体积。
• 合理设置依赖scope：对于运行环境已经预置的依赖（比如Web容器自带的servlet-api、Spring Boot部署到外置容器时的tomcat starter），将scope设置为provided，打包时会自动排除这类依赖，不会打入uber jar。
• 定期清理无效依赖：执行mvn dependency:tree命令输出完整依赖树，排查不需要的传递依赖，通过exclusion标签手动排除，同时移除项目中没有实际引用的直接依赖。

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