第 2 章 POM 深潜:生命周期机器与插件军团 本章要回答的三个问题: 敲下 mvn package 之后,机器内部按什么顺序、跑了哪些步骤? Maven 号称"生命周期",为什么真正干活的全是插件?它们怎么绑定、怎么被调用? 同一套代码,怎么在测试、预发、生产三种环境打出三个不同的包? 为什么会有这一章 第 1 章的作战记录里反复出现 、 这类名字,很多工程师看了三年日志仍说不清它们从哪来、何时被调用。这种模糊在平时无伤大雅,一旦构建行为异常——测试没跑、资源没拷贝、打出来的包结构不对——就没有排查抓手了。 本章把构建机器拆开讲:先沿着一次完整构建走完三套生命周期(2.1),再看插件这台"真正的发动机"如何绑定阶段、如何自研(2.
本章要回答的三个问题:
- 敲下 mvn package 之后,机器内部按什么顺序、跑了哪些步骤?
- Maven 号称"生命周期",为什么真正干活的全是插件?它们怎么绑定、怎么被调用?
- 同一套代码,怎么在测试、预发、生产三种环境打出三个不同的包?
第 1 章的作战记录里反复出现 maven-compiler-plugin、maven-surefire-plugin 这类名字,很多工程师看了三年日志仍说不清它们从哪来、何时被调用。这种模糊在平时无伤大雅,一旦构建行为异常——测试没跑、资源没拷贝、打出来的包结构不对——就没有排查抓手了。
本章把构建机器拆开讲:先沿着一次完整构建走完三套生命周期(2.1),再看插件这台"真正的发动机"如何绑定阶段、如何自研(2.2),最后解决同代码多环境的问题——Profile 与资源过滤(2.3)、Assembly 定制交付物(2.4)。读完本章,mvn 输出里的每一行插件日志你都能说出它的来龙去脉。
mvn 某阶段 背后实际执行了什么;
| 节号 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 2.1 一次完整构建的旅程 | 机器内部执行顺序 | 生命周期阶段地图与日志解读能力 |
| 2.2 插件是生命周期的执行者 | 谁在真正干活 | 绑定机制认知与一个可运行的自研插件 |
| 2.3 Profile 与资源过滤 | 同代码多环境 | 三环境打包方案与占位符冲突规避 |
| 2.4 Assembly 交付物打包 | 定制交付形态 | 描述文件编写能力与打包方案选型表 |
有。不带 clean 的 install 是增量构建:target 目录里的旧产物不被清除,极端情况下过期的类文件混进新包,制造"改了代码没生效"的假象。带 clean 多花几秒,换来确定性。本地出包建议永远带上它。
两种可能:goal 没有绑定到阶段(只写了插件声明没写 executions,某些 goal 就不会自动跑);或者你执行的命令没走到它绑定的阶段。用第 1.4 节的有效 POM 看最终绑定,用构建日志数插件执行行数,两边对不上就说明配置没生效。
不用背全表。记住骨架(validate、compile、test、package、verify、install、deploy 的主干顺序)加上"执行即前置"这一条语义,剩下的查表即可。真正的分水岭是理解"阶段是空壳、插件是执行者"——有了这个模型,任何构建行为你都能推导出它挂在哪个阶段。
本章结束时,构建机器对你不再是一个黑箱。第 3 章将进入全册的核心战役:这台机器在解析依赖时的调解规则、传递路径与仲裁制度——正是它们决定了你的 classpath 里最终站着哪个版本的构件。