Maven POM继承、聚合或依赖

Question

• 我们的团队每年为我们公司的不同部门开发大约5个网络应用程序。
• 应用程序没有关联，它们有自己的应用服务器、数据库和基于DB的用户，没有单一的登录服务器或公共数据库。
• 每个新项目，我们都重新创建Java &Javascript的通用代码，如用户管理、菜单管理、代码描述、安全性等(复制/粘贴以前的项目)。
• 外观和感觉是根据需求变化的。
• 现在，我们创建了一个util项目，它有一些常见的方法(如电子邮件、电话号码验证器、日期时间使用程序、日期序列化程序等)。
• 新项目使用util项目作为依赖项。
• 当我们发现需要新的util方法时，我们将其添加到util项目中，并发布一个新版本(util项目具有自己的生命周期)。如果需要，其他项目可以升级到新版本的util。

我们的技术栈是Spring - spring、安全性、数据-JPA和角JS & Thymeleaf。

现在，我希望避免为每个项目重新创建常见的内容(用户、菜单代码描述等)。

我对多模块maven项目没有实际知识，所以无法决定什么是最佳实践。

这里有选择吗？

• 创建父项目(包括用户、菜单服务、存储库、实体类等)并继承到其他项目中。(只有父pom或具有类的父项目)
• 创建作为一个模块和聚合的公共事物。(如何管理生命周期？)
• 创建具有自己生命周期的独立maven项目，并将其用作依赖项(客户机端脚本将发生什么)。

想知道最好的做法。

Answer 1

共享库的第一条规则--不要创建共享库。在每个组织中的某个时候，都有人试图共享他们从一个项目复制到另一个项目的代码。几年后，它变得不可能维持。

除非您能够创建一个高质量的库(至少在理论上)可以开放源代码，否则您将不会为您的公司带来任何好处。

如果您确实希望创建一个高质量的可重用库，那么下面是一些规则：

• 库或一组连接的库通常驻留在单独的项目(存储库)中。
• 库不应该是特定于项目的，也不应该是特定于公司的，它需要非常通用，这样其他组织的人才能在理论上使用它。
• 它应该与开源库的外观相同--您只需将它作为另一个依赖项来包含。
• 它们不能覆盖从顶部(UI)到底部(后端实体)的特性。每个库都有自己的小任务要完成。如果它是一个UI组件-那么它是一个可重用的NPM包，如果它是一个用于普通计算的Java实用程序-那么它应该是那个实用程序，就是它。多个包之间的相互连接应该非常有限(如果有的话)。
  • 如果您确实希望共享自上而下的功能，请考虑创建一个独立的应用程序，以及服务到服务的通信、iframes等的可能性。

​

• 不应将Spring上下文包含到可重用库中。Spring是每个独立应用程序的一部分，不能共享。

因此，在创建共享库之前要三思，并准备花费大量时间来维护它。