企业官网建设流程全解析

摘要：维护一个 30+ 模块的多模块工程（芋道架构风格），版本管理的三个老大难：改版本要全工程替换、BOM 的版本号与父 POM 版本耦合、依赖冲突排查靠运气。这篇文章讲我们把版本号统一到${revision}+ flatten-maven-plugin、内部依赖用 BOM 收口的完整改造过程，以及 Enforcer 插件如何把"依赖冲突"从线上事故变成构建期报错。

关键词：Maven 多模块、revision、flatten-maven-plugin、BOM、依赖冲突

适合人群：维护多模块 Java 工程的开发者

一、痛点清单（改版本改到怀疑人生的来源）

1. 版本号散落：30+ 模块的 parent/version/依赖版本逐个改，漏一个就构建失败或版本漂移
2. install 后的 install 悖论：${project.version}会被打进安装到本地仓库的 POM，下游引用后 CI 环境解析失败（版本占位符未被解析的著名坑）
3. 依赖冲突静默发生：两个模块依赖不同版本的同一个库，Maven"就近原则"选了错的那个，线上 NoSuchMethodError 才暴露
4. 内部模块互相引用版本乱：A 依赖 B 1.0.0，B 已升级 1.0.1，A 不改就一直跑旧版

二、${revision} + flatten：版本号单一事实源

<!-- 根 pom --><properties><revision>2.1.0</revision></properties><modules>...</modules><!-- 所有子模块 --><parent><groupId>com.hilink</groupId><artifactId>hilink-dependencies</artifactId><version>${revision}</version></parent><artifactId>hilink-module-system</artifactId><!-- 子模块不再写 version，模块间依赖也用 ${revision} -->

发版时只改根 POM 一处：mvn versions:set -Drevision=2.2.0（或直接改一个文件），全工程版本同步。

但${revision}会让 install/deploy 出去的 POM 带着未解析的占位符（痛点 2），flatten-maven-plugin 是官方解法：

<plugin&