Maven POM 继承或聚合或依赖

Question

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

我们的技术栈是 Spring boot - spring MVC、security、data-JPA & Angular JS & Thymeleaf

现在我想避免为每个项目重新创建常见的东西（用户、菜单代码描述等）。

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

这里是选项？

• 创建父项目（使用用户、菜单服务、存储库、实体类等）并继承到其他项目。 （仅父 pom 或带有类的父项目）
• 将常用的东西创建为一个模块并聚合。（如何管理生命周期？）
• 用自己的独立maven项目创建通用的东西 生命周期并将其用作依赖项。（客户端脚本会发生什么）

想知道最佳实践。

Answer 1

共享库的第一条规则 - 不要创建共享库。在每个组织中的某个时刻，都会有人尝试共享他们在项目之间复制的代码。几年后，它变得无法维持。

除非您可以创建一个（至少在理论上）可以开源的高质量库，否则您不会为您的公司带来任何好处。

如果你确实想创建一个高质量的可重用库，那么这里有一些规则：

• 一个库或一组连接的库通常位于单独的项目（存储库）中。
• 一个库不应该是特定于项目或公司的，它需要非常通用，以便其他组织的人理论上可以使用它
• 它应该看起来与开源库相同 - 您只需将其作为另一个依赖项包含在内。
• 它们无法覆盖从顶部 (UI) 到底部（后端实体）的功能。每个图书馆都有自己的小任务要完成。如果它是一个 UI 组件——那么它就是一个可重用的 NPM 包，如果它是一个用于通用计算的 Java 实用程序——那么它应该是那个实用程序，仅此而已。多个包之间的互连应该非常有限（如果有的话）。
  • 如果您确实想要共享自上而下的功能，请考虑创建一个独立的应用程序以及服务到服务通信、iframe 等的可能性。
• 不应将 Spring 上下文包含到可重用库中。 Spring 是每个独立应用程序的一部分，不能共享。

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