Ear vs multimodule打包策略

Question

我开发内部Java EE应用程序。它们都共享核心功能集，例如JPA Entities (Employee.class), Session Beans (EmployeeService.class), Filters (Authenticate.class), Logging (Log4J2)等......

我创建了一个Java Utility项目，并将这些类com.mydomain.mylastname.core.(filter|domain|loggin)打包到.jar中。

然后我将使用JBoss Central start from scratch

创建一个动态Web项目

我一直将core作为POM依赖项包含在内。这是正确的方法，还是我应该做多模块或耳朵？

我问，因为我有另一个案例，webapp项目不断扩展，我在同一个Eclipse项目中用包文件夹分隔了更多功能。

com.mydomain.mylastname.functionality1
com.mydomain.mylastname.functionality2
com.mydomain.mylastname.functionality3

我认为将每个功能包重新组织并移动到自己的Eclipse / Maven项目中会更有意义。这样，如果只有一件更新，我就不必重新部署大量未更改的源代码。

但是，我如何将它们打包成一个可部署的app / frontend呢？作为EAR还是MultiModule？每个功能基本上都是网页导航菜单中的下拉菜单。也许我让这个太复杂了，最简单的方法是让HTML前端简单指向每个单独部署的应用程序......但是我的菜单栏需要在所有三个应用程序中维护。我想分享所有（JSF）模板，css，图像。

任何建议都非常感谢。

Answer 1

如果我理解正确，这是你的基本问题：你的网络应用程序项目中有很多独立的软件包。您不确定是否要将它们作为单独的maven模块。

以下几点需要考虑：

• 您应该将整个应用程序工件构建为单个部署工件。即使有一条变化线。这没关系。
• 您的应用程序li​​b文件夹或maven依赖项可以包含许多其他库 - 所有这些都可以打包到部署工件中。这里的库不会被更改或源代码管理。它们与您的应用程序一起打包，具有已知的版本
• 您可以将公共库/实用程序jar类型代码推送到核心模块或其他模块，并将该源代码作为单独的maven模块进行管理
• 即使您的应用程序源代码达到100个模块，仍然可以轻松地使用git，svn等源代码控制系统进行管理。只要代码的生命周期（构建，测试，发布）相同，您就可以把它们作为一个单元。
• 如果您希望在每次需要部署代码时，可以在100多个maven模块中破坏应用程序代码，每个模块都需要构建为聚合的多模块maven构建。然后你需要一个整体的包装模块来将所有100件文物包装在耳朵或战争中或根据需要包装。

Answer 2

这更多是个人选择，但是在编写基于多模块和依赖项的项目后，我更倾向于使用依赖项。

我的理由是：

• 依赖关系可以缩短构建时间，因为它们已经构建完毕。
• 每次更改父pom项目时，不必更改依赖关系（父pom版本）
• 查看依赖项更简单，因为它不会包含在父项目的审核中（如果您更改版本）
• 你的项目上传和下载（这里是git）会更快，因为只能根据需要下载依赖项（一旦你第一次运行maven下载依赖项），而每次你都会删除并重新构建模块在父级上点击mvn clean verify，这会降低你的速度。

关于第二个问题：如何部署它们。

如果他们必须以模块（耳朵）的形式运行，那么策略就是尽可能地将依赖关系隔离到可重用的组件中，这些组件可以被一个非常基本的Web shell使用，它可以支持Web服务器。例如，您可以拥有一个加载依赖项的模块。

另一个替代方案是创建一个作为ear文件的依赖项，并且有一个maven汇编程序将依赖项打包为app。这可能比为依赖项定义瘦shell更简单。以下是有关如何使用汇编程序插件从依赖项创建应用程序的参考：http://maven.apache.org/plugins/maven-assembly-plugin/

编辑： 日历，分享照片，聊天等...

他们之间的互动方式远远超出了Maven和模块/依赖关系。例如，版本控制很重要吗？您可以针对日历版本3部署聊天版本4吗？他们共享同一个数据库吗？对数据库的正常运行时间有哪些要求？它是分布式应用程序吗？

这个列表一直在继续，一个简单的答案变得越来越难。

假设您拥有支持上述所有内容的基础架构，并且您正在寻找的是指南，那么我会说Calendar，Photoshare，Chat实际上是具有既定合同的服务。在这种情况下，我会将它们分成不同的项目，原因很简单，不同的团队可以更容易地独立工作。我在此考虑，随着这些服务功能的增长，您将需要专门的团队，为此，最好的选择是项目。与Maven无关，只是上市时间。

Answer 3

我认为我们必须首先明确多模块和耳朵这两个术语。多模块是Maven项目结构，其中每个模块都生成自己的工件。耳是企业档案，可以是其中一个模块的结果。

选择结构取决于发布周期。如果所有工件总是一起发布，则应将它们放在单个多模块项目中。如果其中一个工件（例如实用工具）被多个项目使用，则不要将其用作多模块项目的一部分。