我正在构建一个基于前端(读取:面向网络)HTTP API 的分布式应用程序，该 API 调用底层(读取:非面向网络)Thrift 服务。
举个例子，我可能有:
- authentication-service(包含认证代码)
- 核心服务(包含生成的 thrift 源和一些公共(public)类，例如服务发现和初始化逻辑)
所有单独的服务都依赖于核心服务，面向 HTTP 网络的 API 也是如此。我现在将其作为一个多模块项目，但我希望每个项目都是独立的(并在它们自己的存储库中进行跟踪 - 尽管我知道我仍然可以通过多模块构建来做到这一点)。
tl;dr -
拥有一个单独构建的模块(核心服务)然后推送到 Maven 存储库(然后作为 jar 包含在其他项目中)是一种常见的构建实践，还是在这种情况下会更好做一个多模块项目？
最佳答案
我个人尽量避免多模块项目，因为如果您使用 Maven Release Plugin ，您被锁定在一起发布所有模块。
虽然这听起来很方便，但当您需要对其中一个模块进行错误修复发布时，问题就出现了——您最终发布了所有模块，而不仅仅是带有错误修复的模块，增加了它们的版本，即使它们没有改变。
如果您在多模块项目中运行 CI，您也会受到打击 - 您构建通常会从根 pom 运行所有模块，但如果您在特定模块中工作，您最终会受到打击构建那些没有改变的东西，实际上失去了模块化本应提供的一些好处。
因此，使用独立模块，但这是重要的一点，创建一个共同的“依赖”pom，供每个模块使用。
'dependency' pom 是一种标准化项目中所有依赖项的 pom，不同之处在于这些依赖项是在 dependencyManagement 部分而不是 dependencies 中指定的部分(它还设置标准插件配置等)。这允许您的项目 poms 将依赖项 pom 指定为它们的父级，然后声明它们需要的依赖项减去版本，这些版本是从“依赖项”pom 中获取的，因此在您的项目中标准化。
如果您仍然担心能否构建所有内容，这可以通过一个简单的批处理文件来实现。
关于java - Maven 多模块项目结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17146708/