J2EE Web应用与REST客户端的Maven/Git/Jenkins架构问题咨询

先理清楚你的当前项目结构，方便后续分析：

现有项目结构 #

Web应用（Git子模块管理） #

web-app (父模块)
├── ejb (子模块)
├── war (子模块)
├── model (子模块，已部署至Maven仓库)
└── ejb-client (子模块，已部署至Maven仓库)

web-app用git submodules管理所有子模块，每个子模块都在web-app目录下有独立目录，Jenkins能通过web-app中记录的子模块commit hash精准编译任意分支，这一点做得非常好。

REST客户端 #

rest-client
├── ejb-client (依赖)
└── model (依赖)

REST客户端需要拉取已部署到Maven仓库的model和ejb-client，但目前因为这两个模块依赖web-app父POM，导致拉取失败。

问题1：能否在POM中配置替代mvn deploy -N单独部署父POM？ #

当然可以，不用每次手动执行mvn deploy -N。这里有两种更优雅的方案：

方案一：让父POM自动部署 #

在web-app的父POM中配置maven-deploy-plugin，确保父POM在子模块部署前自动推送到仓库：

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-deploy-plugin</artifactId>
      <version>3.1.1</version>
      <executions>
        <execution>
          <id>deploy-parent-pom</id>
          <phase>deploy</phase>
          <goals>
            <goal>deploy</goal>
          </goals>
          <configuration>
            <skip>false</skip>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

这样当你部署model或ejb-client时，父POM会先被部署到仓库，REST客户端就能正常拉取依赖了。

方案二：抽离独立的父POM #

如果web-app的父POM只是做通用的依赖管理、插件配置，完全可以把它拆成一个独立的Maven项目（甚至可以放在同一个Git仓库的独立目录），单独部署到仓库。让model、ejb-client、web-app、rest-client都依赖这个独立父POM，从根源上解除model和ejb-client对web-app模块的依赖，这是更彻底的解耦方案。

问题2：是否应该把model和ejb-client从web-app子模块移除？ #

你的顾虑完全正确——如果把这两个模块从web-app的Git子模块中移除，Jenkins就失去了父模块与子模块的commit hash关联，无法精准追踪每个分支对应的子模块版本，这对持续集成和版本回溯是致命的。

但我们可以做折中调整：

• 继续保留model和ejb-client作为web-app的Git子模块，维持commit hash的关联，确保Jenkins能正确编译任意分支；
• 让web-app的ejb、war子模块通过Maven依赖引用model和ejb-client，而不是通过模块聚合的方式。这样编译时依然能从本地子模块目录获取最新代码，同时不影响Maven依赖的传递性。

整体结构合理性与最终调整建议 #

当前结构的核心优势——用Git子模块保证模块版本强关联——非常适合持续集成，但model和ejb-client依赖web-app父POM导致REST客户端无法拉取依赖是明显的痛点。

我建议的调整方向：

1. 抽离独立父POM：把web-app中通用的父POM配置拆成独立项目，单独部署到Maven仓库，让所有模块（包括rest-client）都依赖这个独立父POM，解除耦合；
2. 保留Git子模块关联：继续把model和ejb-client作为web-app的Git子模块，维持commit hash的追踪能力；
3. 调整web-app内部依赖方式：让ejb、war通过Maven依赖引用model和ejb-client，而不是模块聚合，兼顾本地开发的便利性和依赖的规范性。

这样调整后，既保留了Git子模块的版本追踪优势，又解决了REST客户端的依赖问题，结构更清晰，耦合度更低，也更符合Maven的最佳实践。

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