拆分大型Maven项目时能否保留Reactor Sorting、父POM等特性？

我来分享一套在实际项目中验证过的方案，能同时满足你提出的四个核心要求：

1. 核心思路：分离通用父POM + 聚合元仓库 #

核心是把原来单体仓库里的通用配置层和业务模块层彻底分离，再通过一个轻量的聚合仓库实现全局构建的依赖排序，既保留单体仓库的配置优势，又获得多仓库的灵活性。

2. 分步实施细节 #

第一步：抽离通用父POM为独立仓库并发布 #

把原来单体仓库中的父POM单独拎出来，做成一个独立的Git仓库（比如命名为company-maven-parent）：

• 清理父POM中仅和单体仓库绑定的配置（比如特定模块的路径引用），只保留通用部分：
  • 全局属性（如spring.version、hibernate.version）
  • <dependencyManagement>统一依赖版本
  • <pluginManagement>统一插件版本和配置
  • 通用的仓库镜像、部署配置等
• 把这个父POM发布到你们内部的Maven仓库（Nexus/Artifactory都可以），使用语义化版本号（比如1.0.0），后续更新时升级版本即可。

第二步：拆分业务模块为独立Git仓库 #

对每个业务模块单独创建Git仓库：

• 修改模块的pom.xml，将<parent>指向刚发布的通用父POM坐标：

  <parent>
      <groupId>com.yourcompany</groupId>
      <artifactId>company-maven-parent</artifactId>
      <version>1.0.0</version>
  </parent>
  

• 删除模块POM中重复的依赖管理、插件配置（这些已经由父POM接管），只保留模块自身的业务依赖、必要的插件覆盖配置，以及模块专属的构建逻辑。
• 将每个模块的代码推送到对应的独立Git仓库。

第三步：创建聚合元仓库实现全局Reactor构建 #

为了实现全局构建的依赖自动排序，我们需要一个轻量的聚合元仓库（比如命名为project-aggregator）：

• 这个仓库不存放业务代码，只包含一个聚合POM（<packaging>pom</packaging>），并通过Git子模块关联所有业务模块：
  1. 初始化仓库后，执行命令添加子模块：

     git submodule add git@your-git-server.com:module-a.git modules/module-a
     git submodule add git@your-git-server.com:module-b.git modules/module-b
     # 依次添加所有业务模块
     

  2. 在聚合POM中声明所有模块的路径：

     <modules>
         <module>modules/module-a</module>
         <module>modules/module-b</module>
         <!-- 不需要手动排序，Maven会自动分析依赖关系完成Reactor Sorting -->
     </modules>
     

• 全局构建时，只需要克隆这个元仓库，拉取所有子模块：

  git clone git@your-git-server.com:project-aggregator.git
  cd project-aggregator
  git submodule update --init --recursive
  

  然后执行mvn clean install，Maven会自动按照依赖顺序构建所有模块，和原来单体仓库的Reactor行为完全一致。
• 全局版本更新也很简单：在元仓库中执行mvn versions:set -DnewVersion=2.0.0，提交所有子模块的版本变更后，分别推送到各个模块仓库即可。

第四步：支持单个模块的独立开发 #

开发者完全可以只克隆自己负责的模块仓库：

• 因为通用父POM已经发布到内部Maven仓库，执行mvn clean install时，Maven会自动从仓库拉取父POM以及其他依赖的模块构件（如果本地仓库没有的话）。
• 如果需要修改通用父POM，开发者可以单独克隆company-maven-parent仓库，修改后发布新版本，再更新业务模块中的父POM版本号即可，不会影响其他模块的开发。

3. 关键注意事项 #

• 父POM版本管理：尽量使用语义化版本，避免破坏性变更；如果需要测试新配置，可以先发布快照版本（如1.0.1-SNAPSHOT）验证。
• 内部Maven仓库稳定性：确保所有开发者都能访问到内部仓库，避免构建时拉取依赖失败。
• Git子模块操作：给开发者做简单的子模块操作培训（比如拉取更新、提交子模块变更），如果觉得子模块麻烦，也可以用Git subtree替代，但子模块在独立仓库场景下更灵活。
• CI/CD自动化：配置CI工具（如GitLab CI、Jenkins），当任何一个模块仓库有变更时，自动触发元仓库的全局构建，确保集成稳定性。

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