多构件Maven项目按业务模块组织的实现方案咨询

首先明确：完全可以按业务模块（tasks、clients、suppliers）来组织你的Maven项目，同时彻底解决构建配置重复的问题。结合你的技术栈（Ubuntu 18.04、Java 11、Eclipse+m2e），下面是几种经过实践验证的可行方案：

方案1：分层父模块 + pluginManagement（最推荐） #

这是Maven多模块项目的标准最佳实践，既能保留业务模块的清晰结构，又能集中管理构建配置，彻底避免重复。

调整后的项目结构 #

awesome-root
├── pom.xml  <!-- 全局通用配置：依赖版本、仓库、基础插件版本 -->
├── jar-modules-parent
│   └── pom.xml  <!-- 集中管理所有jar类型构件的maven-jar-plugin等配置 -->
├── war-modules-parent
│   └── pom.xml  <!-- 集中管理所有war类型构件的maven-war-plugin等配置 -->
├── tasks
│   ├── task-model
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   ├── task-logic
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   └── task-ui
│       └── pom.xml  <!-- 父模块指定为war-modules-parent -->
├── clients
│   ├── client-model
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   ├── client-logic
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   └── client-ui
│       └── pom.xml  <!-- 父模块指定为war-modules-parent -->
├── suppliers
│   ├── supplier-model
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   ├── supplier-logic
│   │   └── pom.xml  <!-- 父模块指定为jar-modules-parent -->
│   └── supplier-ui
│       └── pom.xml  <!-- 父模块指定为war-modules-parent -->
└── others
    └── utility
        └── pom.xml  <!-- 父模块指定为jar-modules-parent -->

配置细节 #

1. awesome-root的pom.xml：

   • 作为聚合模块，列出所有子模块（jar-modules-parent、war-modules-parent、tasks、clients、suppliers、others）
   • 在<properties>中定义全局依赖版本、Java编译版本等通用参数
   • 在<pluginManagement>中统一配置所有插件的基础版本（避免子模块重复指定版本）

2. jar-modules-parent的pom.xml：

   • 父模块指定为awesome-root，打包类型设为pom
   • 在<pluginManagement>中配置maven-jar-plugin的特定参数（比如你提到的utility需要的自定义配置）
   • 所有jar类型的子模块（-model、-logic、utility）都将这个模块作为父模块，直接继承插件配置，无需重复编写

3. war-modules-parent的pom.xml：

   • 父模块指定为awesome-root，打包类型设为pom
   • 在<pluginManagement>中配置maven-war-plugin的特定参数（比如client-ui需要的自定义配置）
   • 所有war类型的子模块（*-ui）都将这个模块作为父模块，直接继承插件配置

这样，当你需要修改jar构件的打包规则时，只需要调整jar-modules-parent的pom，所有jar子模块会自动生效；war构件同理，完全避免了重复配置和同步修改的麻烦。

方案2：Maven Profiles + 自动激活（适合灵活场景） #

如果你的构建配置需要根据环境或模块类型动态调整，可以结合Profiles和文件规则自动加载配置：

1. 在awesome-root的pom.xml中定义Profiles：

   <profiles>
       <profile>
           <id>jar-build</id>
           <activation>
               <file>
                   <exists>${project.basedir}/src/main/java</exists>
                   <!-- 自动激活：识别jar模块（存在Java源码目录） -->
               </file>
           </activation>
           <pluginManagement>
               <plugins>
                   <plugin>
                       <groupId>org.apache.maven.plugins</groupId>
                       <artifactId>maven-jar-plugin</artifactId>
                       <configuration>
                           <!-- 你的jar模块专属配置 -->
                       </configuration>
                   </plugin>
               </plugins>
           </pluginManagement>
       </profile>
       <profile>
           <id>war-build</id>
           <activation>
               <file>
                   <exists>${project.basedir}/src/main/webapp</exists>
                   <!-- 自动激活：识别war模块（存在webapp目录） -->
               </file>
           </activation>
           <pluginManagement>
               <plugins>
                   <plugin>
                       <groupId>org.apache.maven.plugins</groupId>
                       <artifactId>maven-war-plugin</artifactId>
                       <configuration>
                           <!-- 你的war模块专属配置 -->
                       </configuration>
                   </plugin>
               </plugins>
           </pluginManagement>
       </profile>
   </profiles>
   

2. 所有业务模块的pom.xml只需要指定父模块为awesome-root，Maven会根据模块的目录结构自动激活对应的Profile，加载对应的插件配置。

这种方案无需额外的中间父模块，适合配置需要动态调整的场景，同时也能避免重复配置。

方案3：自定义Maven Archetypes（适合团队批量创建模块） #

如果你们需要频繁创建同类型的业务模块（比如新增xxx业务，包含model、logic、ui），可以自定义Archetypes来标准化配置：

1. 先创建模板模块（比如template-jar、template-war），包含你需要的所有构建配置
2. 使用maven-archetype-plugin将这些模板打包成Archetypes
3. 之后创建新的业务模块时，直接通过Archetype生成，自动继承正确的配置

这种方案适合团队协作场景，确保所有新模块的配置一致性，但需要前期的Archetype开发和维护。

关于你之前遇到的pluginManagement问题 #

你提到之前尝试pluginManagement但有重复问题，大概率是因为没有正确分层：

• 不要直接在root的pluginManagement中混合jar和war的配置，而是通过中间父模块分类管理
• 确保子模块正确指定父模块，并且在子模块的<build><plugins>中只需要声明插件（不需要重复配置，除非要覆盖父模块的规则）

总结 #

你完全不需要退回到按构建类型组织项目，按业务模块组织是更合理的选择，以上方案都能完美解决配置重复的问题。其中方案1（分层父模块+pluginManagement）是最通用、最易维护的方案，完全适配你的技术栈，Eclipse的m2e插件也能很好地识别这种结构，不会有兼容性问题。

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