1. 问题现象与背景疑惑最近在Java项目构建时遇到一个有趣现象明明没有显式配置maven-assembly-plugin或maven-shade-plugin这类专门打包Fat JAR的插件但最终生成的JAR包却包含了所有依赖库。这让我产生了两个疑问为什么没有专用插件也能生成Fat JAR不同打包插件之间究竟存在怎样的协作或冲突关系通过分析Maven核心机制和插件默认行为发现这背后涉及Maven生命周期的阶段绑定、插件默认配置以及各打包工具的设计哲学。下面通过具体案例拆解其中的运作原理。2. Maven基础构建流程解析2.1 标准打包生命周期阶段Maven构建过程分为三套独立生命周期clean/default/site其中default生命周期包含项目编译打包的核心阶段。与JAR打包直接相关的阶段包括process-resources处理资源文件compile编译主代码process-test-resources处理测试资源test-compile编译测试代码test运行单元测试package打包构建产物install安装到本地仓库deploy部署到远程仓库2.2 maven-jar-plugin的默认绑定在pom.xml未显式配置时Maven会为packaging为jar的项目自动绑定maven-jar-plugin到package阶段。这是通过Maven核心的default生命周期映射实现的。通过命令可查看实际绑定的插件mvn help:effective-pom -Dverbose | grep maven-jar-plugin输出示例显示默认配置plugin artifactIdmaven-jar-plugin/artifactId version3.2.0/version executions execution iddefault-jar/id phasepackage/phase goals goaljar/goal /goals /execution /executions /plugin3. Fat JAR生成的三种典型场景3.1 场景一默认打包的伪Fat JAR当项目仅依赖maven-jar-plugin时生成的JAR可能包含部分依赖这通常由以下原因导致依赖scope为system通过systemPath指定的本地依赖会被直接包含未声明依赖scope默认compile范围的依赖可能被内联资源文件包含依赖src/main/resources目录下的库文件会被打包注意这种伪Fat JAR往往缺少传递依赖运行时会出现ClassNotFoundException3.2 场景二assembly-plugin的归档策略maven-assembly-plugin通过descriptorRef配置实现全量打包。典型配置plugin artifactIdmaven-assembly-plugin/artifactId executions execution phasepackage/phase goalsgoalsingle/goal/goals configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration /execution /executions /plugin其工作原理是在package阶段后执行绑定到phase收集所有runtime范围的依赖解压依赖JAR后重新压缩到最终包中3.3 场景三shade-plugin的字节码融合maven-shade-plugin提供更高级的功能plugin artifactIdmaven-shade-plugin/artifactId executions execution phasepackage/phase goalsgoalshade/goal/goals configuration transformers transformer implementation... mainClasscom.example.Main/mainClass /transformer /transformers /configuration /execution /executions /plugin与assembly-plugin的区别处理依赖冲突时进行类重命名relocation支持合并ServiceLoader配置文件可自定义主类清单MANIFEST.MF4. 插件执行顺序的深度解析4.1 生命周期阶段与插件执行顺序当多个插件绑定到同一阶段时执行顺序由pom.xml中的声明顺序决定。例如build plugins plugin !-- 先执行的插件 -- /plugin plugin !-- 后执行的插件 -- /plugin /plugins /build4.2 典型冲突案例假设同时配置了jar-plugin和shade-pluginjar-plugin先执行生成原始JARshade-plugin后执行生成shaded JAR最终仓库安装的是最后一个插件生成的产物可通过指定classifier区分不同产物configuration classifieroriginal/classifier /configuration5. 生产环境最佳实践5.1 插件选型建议需求场景推荐插件理由简单可执行JARmaven-jar-plugin轻量级无需额外配置包含第三方依赖maven-assembly-plugin配置简单支持多种格式需要处理依赖冲突maven-shade-plugin类重命名解决冲突Spring Boot项目spring-boot-maven-plugin专为Boot应用优化5.2 常见问题排查指南问题一依赖缺失检查依赖scope是否为runtime/provided确认是否配置了正确的descriptorRef问题二主类未生效确认MANIFEST.MF是否包含Main-Class对于shade插件检查transformer配置问题三重复类冲突使用shade插件的relocation功能relocations relocation patterncom.google.guava/pattern shadedPatternshaded.com.google.guava/shadedPattern /relocation /relocations6. 底层机制原理解析6.1 Maven依赖解析机制Maven通过以下顺序解析依赖本地仓库查找中央仓库下载根据scope过滤依赖compile传递依赖provided不打包runtime打包但不编译6.2 插件覆盖规则当多个插件声明相同goal时子pom配置覆盖父pom后声明的插件覆盖先声明的显式配置覆盖默认配置可通过mvn help:effective-pom验证最终生效的配置。
1. 问题现象与背景疑惑最近在Java项目构建时遇到一个有趣现象明明没有显式配置maven-assembly-plugin或maven-shade-plugin这类专门打包Fat JAR的插件但最终生成的JAR包却包含了所有依赖库。这让我产生了两个疑问为什么没有专用插件也能生成Fat JAR不同打包插件之间究竟存在怎样的协作或冲突关系通过分析Maven核心机制和插件默认行为发现这背后涉及Maven生命周期的阶段绑定、插件默认配置以及各打包工具的设计哲学。下面通过具体案例拆解其中的运作原理。2. Maven基础构建流程解析2.1 标准打包生命周期阶段Maven构建过程分为三套独立生命周期clean/default/site其中default生命周期包含项目编译打包的核心阶段。与JAR打包直接相关的阶段包括process-resources处理资源文件compile编译主代码process-test-resources处理测试资源test-compile编译测试代码test运行单元测试package打包构建产物install安装到本地仓库deploy部署到远程仓库2.2 maven-jar-plugin的默认绑定在pom.xml未显式配置时Maven会为packaging为jar的项目自动绑定maven-jar-plugin到package阶段。这是通过Maven核心的default生命周期映射实现的。通过命令可查看实际绑定的插件mvn help:effective-pom -Dverbose | grep maven-jar-plugin输出示例显示默认配置plugin artifactIdmaven-jar-plugin/artifactId version3.2.0/version executions execution iddefault-jar/id phasepackage/phase goals goaljar/goal /goals /execution /executions /plugin3. Fat JAR生成的三种典型场景3.1 场景一默认打包的伪Fat JAR当项目仅依赖maven-jar-plugin时生成的JAR可能包含部分依赖这通常由以下原因导致依赖scope为system通过systemPath指定的本地依赖会被直接包含未声明依赖scope默认compile范围的依赖可能被内联资源文件包含依赖src/main/resources目录下的库文件会被打包注意这种伪Fat JAR往往缺少传递依赖运行时会出现ClassNotFoundException3.2 场景二assembly-plugin的归档策略maven-assembly-plugin通过descriptorRef配置实现全量打包。典型配置plugin artifactIdmaven-assembly-plugin/artifactId executions execution phasepackage/phase goalsgoalsingle/goal/goals configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration /execution /executions /plugin其工作原理是在package阶段后执行绑定到phase收集所有runtime范围的依赖解压依赖JAR后重新压缩到最终包中3.3 场景三shade-plugin的字节码融合maven-shade-plugin提供更高级的功能plugin artifactIdmaven-shade-plugin/artifactId executions execution phasepackage/phase goalsgoalshade/goal/goals configuration transformers transformer implementation... mainClasscom.example.Main/mainClass /transformer /transformers /configuration /execution /executions /plugin与assembly-plugin的区别处理依赖冲突时进行类重命名relocation支持合并ServiceLoader配置文件可自定义主类清单MANIFEST.MF4. 插件执行顺序的深度解析4.1 生命周期阶段与插件执行顺序当多个插件绑定到同一阶段时执行顺序由pom.xml中的声明顺序决定。例如build plugins plugin !-- 先执行的插件 -- /plugin plugin !-- 后执行的插件 -- /plugin /plugins /build4.2 典型冲突案例假设同时配置了jar-plugin和shade-pluginjar-plugin先执行生成原始JARshade-plugin后执行生成shaded JAR最终仓库安装的是最后一个插件生成的产物可通过指定classifier区分不同产物configuration classifieroriginal/classifier /configuration5. 生产环境最佳实践5.1 插件选型建议需求场景推荐插件理由简单可执行JARmaven-jar-plugin轻量级无需额外配置包含第三方依赖maven-assembly-plugin配置简单支持多种格式需要处理依赖冲突maven-shade-plugin类重命名解决冲突Spring Boot项目spring-boot-maven-plugin专为Boot应用优化5.2 常见问题排查指南问题一依赖缺失检查依赖scope是否为runtime/provided确认是否配置了正确的descriptorRef问题二主类未生效确认MANIFEST.MF是否包含Main-Class对于shade插件检查transformer配置问题三重复类冲突使用shade插件的relocation功能relocations relocation patterncom.google.guava/pattern shadedPatternshaded.com.google.guava/shadedPattern /relocation /relocations6. 底层机制原理解析6.1 Maven依赖解析机制Maven通过以下顺序解析依赖本地仓库查找中央仓库下载根据scope过滤依赖compile传递依赖provided不打包runtime打包但不编译6.2 插件覆盖规则当多个插件声明相同goal时子pom配置覆盖父pom后声明的插件覆盖先声明的显式配置覆盖默认配置可通过mvn help:effective-pom验证最终生效的配置。
