Eclipse Ear与多模块包装策略

我开发内部JavaEE应用程序。它们都共享一组核心功能，例如JPA

实体（Employee.class）、会话bean（EmployeeService.class）、过滤器（Authenticate.class）、日志（Log4J2）

，等等

我创建了一个

Java实用工具

项目，并将这些类

com.mydomain.mylastname.core.（filter | domain | loggin）

打包到一个.jar中

然后，我将使用JBoss Central创建一个动态Web项目

start from scratch

我一直将

核心
作为POM依赖项。这是正确的方法还是我应该做多模块或耳朵

我问这个问题是因为我有另一个例子，webapp项目不断扩展更多的功能，我一直在同一个Eclipse项目中与包文件夹分离

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

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

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

非常感谢您的任何建议。
我想我们必须首先弄清楚multimodule和ear的术语。多模块是Maven项目结构，其中每个模块生成自己的工件。ear是一个企业归档文件，可以是其中一个模块的结果

选择您的结构取决于发布周期。如果所有工件总是一起发布，那么应该将它们放在单个多模块项目中。如果其中一个工件（例如一个实用程序jar）被多个项目使用，那么不要将其作为多模块项目的一部分使用。
如果我理解正确，这是您的基本问题：您的web应用程序项目中有许多独立的包。您不确定是否希望将它们作为单独的maven模块

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

以下是需要考虑的几点：


您应该将整个应用程序构件构建为单个部署构件单元。即使只有一行变化。这没关系
您的应用程序库文件夹或maven依赖项可以包含许多其他库-所有这些都可能打包到部署工件中。在这里，库不会被更改或进行源代码管理。它们只是与您的应用程序打包在一起，具有已知的版本
您可以将公共库/实用程序jar类型的代码推送到核心模块或其他模块，并将该源代码作为单独的maven模块进行管理
即使您的应用程序源代码达到100个模块，也应该很容易使用git、svn等源代码控制系统进行管理。只要代码的生命周期（构建、测试、发布）相同，您就可以将它们作为一个单元进行管理
如果您希望将应用程序代码分解为100个maven模块，每次需要部署代码时，都需要将每个模块构建为聚合的多模块maven构建。然后，您需要一个整体打包模块来打包ear或war中的所有100个工件，或者根据需要打包
这更多是个人的选择，但由于编写了基于多模块和依赖关系的项目，我更倾向于使用依赖关系

我的理由是：


依赖关系可以加快构建时间，因为它们已经构建好了
不必每次更改父pom项目时都更改依赖项（父pom版本）
对依赖项的审阅更简单，因为它不会包含在父项目的审阅中（如果更改版本）
您的项目上载和下载（此处为git）将更快，因为依赖项将仅在需要时下载（一旦您第一次运行maven下载依赖项），而每次在父级上点击
mvn clean verify
，模块将被删除并重新构建，这将降低您的速度

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

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

另一种选择是创建一个作为ear文件的依赖项，并使用maven汇编程序将依赖项打包为应用程序。这可能比为依赖项定义薄壳更简单。以下是有关如何使用assembler插件从依赖项创建应用程序的参考：

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

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

清单上的问题层出不穷，一个简单的答案变得越来越难

假设您拥有支持上述所有内容的基础设施，并且您所寻找的只是指导原则，那么我会说日历、照片共享、聊天实际上是具有既定合同的服务。在这种情况下，我会将它们放入不同的项目中，原因很简单，不同的团队更容易独立处理它们。我在这里考虑的是，随着这些服务功能的增长，您将需要专门的团队，为此，最好的替代方案是项目。诺西