Ear vs 多模块封装策略答案

【问题标题】：Ear vs multimodule Packaging strategyEar vs 多模块封装策略
【发布时间】：2014-08-15 20:40:08
【问题描述】：

我在内部开发 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 项目中更有意义。这样，如果只有一个更新，我就不必重新部署大量未更改的源代码。

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

任何建议都非常感谢。

【问题讨论】：

标签： eclipse maven jakarta-ee

【解决方案1】：

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

我的理由是：

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

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

如果它们必须作为模块（ears）运行，那么策略就是尽可能地将依赖项隔离到可重用的组件中，这些组件可以由一个非常基本的 Web shell 使用，该 shell 可以在 Web 服务器后面支持它们。例如，您可以有一个加载依赖项的模块。

另一种选择是创建一个依赖项，它是一个 ear 文件，并有一个 maven 汇编程序将依赖项打包为一个应用程序。这可能比为您的依赖项定义一个瘦壳更简单。以下是有关如何使用 assembler 插件从依赖项创建应用程序的参考：http://maven.apache.org/plugins/maven-assembly-plugin/

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

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

清单不断增加，一个简单的答案变得越来越难。

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

【讨论】：

我应该澄清我的第二个问题，“功能的包装” - 功能不相互依赖，因为共同的核心内容是我所有项目的核心。我谈论的是创建一个在线应用程序，例如博客系统，其中一个功能是日历，另一个是照片共享，第三个是聊天工具。您会创建单独的 Eclipse maven 项目，还是将所有这些都放在同一个项目中并使用 Java 包分离代码？

【解决方案2】：

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

这里有几点需要考虑：

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

【讨论】：

【解决方案3】：

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

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

【讨论】：