我正在构建一个基于前端（读取：面向Web的）HTTP API的分布式应用程序，该API调用底层（读取：非面向Web的）Thrift服务。
作为一个例子，我可能有：
所有单独的服务都依赖于核心服务，HTTP面向Web的API也是如此。我现在将它作为一个多模块项目，但我希望每个项目都是独立的（并在他们自己的存储库中进行跟踪 - 尽管我知道我仍然可以通过多模块构建来实现这一点。）
tl; dr -
有一个模块（核心服务）是一个常见的构建实践，它是单独构建的，然后推送到maven repo（然后作为jar包含在其他项目中），或者在这种情况下会更好吗？做一个多模块项目？
答案 0 :(得分：14)
就我个人而言，我试图避免使用多模块项目，因为如果你使用Maven Release Plugin，你就会被锁定在一起发布所有模块。
虽然这可能听起来很方便，当您需要对其中一个模块执行错误修复发布时，问题就出现了 - 您最终会释放所有模块，而不仅仅是修复了错误的模块，即使它们增加了版本没有改变。
如果您正在使用多模块项目运行CI，那么您也会受到欢迎 - 您的构建通常会运行来自您的根pom的所有模块，但如果您在特定模块中工作，则最终会受到影响建立那些没有改变的，实际上失去了模块化所要提供的一些好处。
所以，请使用独立模块，但这是重要的一点，创建一个共同的'依赖'pom。
'dependency'pom是一个标准化项目中所有依赖项的pom，不同之处在于，dependencyManagement部分而不是dependencies部分指定了这些依赖项（它还设置了标准插件配置等）。这允许您的项目poms将依赖项pom指定为其父项，然后声明它们所需的依赖项减去版本，这些版本从“依赖项”pom中获取并因此在您的项目中进行标准化。
如果您仍然担心能够构建所有内容，可以使用简单的批处理文件来实现。
答案 1 :(得分：7)
我想说多模块项目更好。如果将核心服务放在存储库中，开发人员应该关心版本。 Developer1需要旧服务，但Developer2更新服务。
多个分支也可能是个问题。
答案 2 :(得分：5)
当所有单个模块具有彼此相同的生命周期时，应该优先考虑多模块构建...换句话说，当它们总是一起发布时，它们的版本号一起增加等等。等等。
OSS领域的一个很好的例子是apache camel project。例如，所有捆绑组件都以individual modules形式存在，可以单独包含在项目中，但与camel核心分发相同的生命周期。
Maven多模块构建在将项目放入CI或在IDE中加载时允许一些方便，但一般来说，如果所有单个模块不共享相同的生命周期，那么多 - 模块项目不太适合
答案 3 :(得分：3)
原则上，让项目尽可能独立地发展总是更好。然而，这更像是一个组织问题，而不是技术问题。完成所有工作后，您的项目结构应与您的组织保持一致。
这归结为保持项目分离并且依赖项目通过本地存储库管理器管理依赖关系，如果它们由不同的人维护或者在不同时间释放它们是有意义的。否则，您可能更适合使用多模块项目结构。
在我们的项目中，我们选择了一种中间选择：我们确实有一个多模块结构，但是所有项目都驻留在独立的Subversion存储库中，因此它们可以单独分支，并且我们使用聚合器项目选择如何通过svn:externals混合和匹配来自不同分支的项目，以便为特定客户创建自定义版本。
缺点是保持类似的结构既复杂又耗时。我们已经开发了大量脚本来部分自动执行这些任务。这是特别繁琐的，因为Maven release plugin无法处理通过Subversion外部连接的模块。