8

我正在寻找一个可以很好地扩展的多模块 maven 项目（如下所述）。我对主要来自Sonatype 示例的方法有一些疑问。

我已经对 Maven 多模块项目进行了一定程度的阅读，但找不到超出基本水平的示例。

问题：

  1. 这是（下）一个好的项目结构吗？或者它从一开始就充满了灾难的味道 - 即在建立构建时会导致大量重组？简而言之，我希望避免设置与 Maven 相悖的东西。
  2. 我期望一些模块是相当独立的，而大多数模块是相互关联的。是否可以将每个模块作为 Git 存储库开始，然后在紧密链接的模块中重构？

目标：

  1. 模块化 Spring、JSF2、Maven 项目的良好项目结构，这将允许构建涉及选择的模块及其依赖项。

  2. 应该可以通过 Maven 配置（如 jetty-maven-plugin）在轻量级容器（如 Tomcat/Jetty）上部署单个 Web 模块。这应该能够通过 Maven 引入必要的依赖项。这使得在开发过程中可以很容易地专注于正在处理的模块（不必运行完整的构建和部署）并仅在完整的构建中部署完整的应用程序。

  3. 该设置应允许基于要包含在构建中的模块选择进行多个分发。我认为这可以通过使用构建模块来实现，该模块将拉取并打包相应的模块。

项目结构

Core domain classes.  
somapp.core (maven project)  
 |- someapp.core (maven module)  
 |- someapp.core.tests  

Account Management Domain classes   
someapp.accountmgmt   
|- someapp.accountmgmt   
|- someapp.accountmgmt.tests   

component1 domain classes   
someapp.component1   
|- someapp.component1   
|- someapp.component1.tests

Service 1 - # account management (User login)
someapp.accountmgmt  
 |- someapp.accountmgmt.api  
 |- someapp.accountmgmt.impl  
 |- someapp.accountmgmt.mocks  
 |- someapp.accountmgmt.tests  

someapp.service2  
 |- someapp.service2.api  
 |- someapp.service2.impl  
 |- someapp.service2.mocks   
 |- someapp.service2.tests   
 |- someapp.service2.cli    # CLI access for service2

someapp.service3  
 |- like above  

someapp.accountmgmt.web  
 |- someapp.accountmgmt.web  

someapp.service2.web  
 |- someapp.service2.web  

someapp.service3.web  
 |- someapp.service3.web  

someapp.build1 # bundle accountmgmt and service2 into 1 war file  

someapp.build2 # bundle accountmgmt and service3 into 1 war file  

somapp.build3 # bundle  accountmgmt, service2 and service3 into 1 war file  

(i.e. someapp.accountmgmt.web.war, someapp.accountmgmt.jar, someapp.service2.web.war, someapp.service2.jar, someapp.service3.web.war, someapp.service3.jar, someapp.core.jar)

我了解项目结构并非一成不变。我想建立一个很好的起点。欢迎提出建议/示例链接。

4

2 回答 2

3

好吧，对于 Spring 部分，它已经讨论过了，并且在Spring Configuration in a multi-module project 中接受了答案。就总体布局而言，我只看到每个项目有一个 WAR，并且服务只有在它们相关时才捆绑在一起（例如，UserLoginService 不会与 DomainObjectsService 一起使用）。

我建议将结构分解为几个不同的项目，将依赖项（业务对象等）作为 JAR 项目部署到本地存储库，并在需要它们的（现在不同的）项目中列为正常的 Maven 依赖项。然后在您的应用服务器中，您可以将应用部署到不同的路径（例如 yourdomain.com/app1、yourdomain.com/service2）。

不过，我对你的野心表示敬意！

编辑：如果您愿意，有一种方法可以拥有多个 WAR，请参阅这篇 SpringSource 博客文章，关于在多战争 Spring 应用程序中使用共享父应用程序上下文。

于 2013-09-23T23:09:00.983 回答
0

从 Spring IO 开始到您的工件的层次结构可以作为单个构建多模块项目来完成。

Spring-IO (dependencies)
   - Your parent pom (custom and further dependency management, plugins etc)
      - someapp-parent (really just a container for each -independent- sub-module)
         someapp-api    (deploy as jar into Nexus
         someapp-remote (Implements API and makes REST calls to your web app - also an independent jar)
         someapp-web    ('war' Exposes REST - JSON - representations of your API domain objects)
         someapp-dashboar (Admin console working with the API/web app via remote so you can manage everything, also a 'war')

顺便说一句，Spring IO 确实很好，因为它是一组可以很好地协同工作并避免类加载器问题的受祝福的依赖项。非常值得迁移您的项目以使用它，因为最新版本看起来相当最新。我还建议将 Spring Boot 用于您的 Web 应用程序。

如前所述，我认为将所有与应用程序相关的模块构建为一个是值得的，因此版本控制更容易，并且您可以在单个构建命令中测试所有内容。我最近参与了一个项目，我们将所有这些模块分开，这意味着合并更改、构建工件、部署工件等的工作量增加了 4 倍。

于 2014-06-30T18:21:43.080 回答