java Maven 多模块项目结构

Maven Multi-Module Project Structure

提问by Colin M

I'm building a distributed application that is based off of a front-end (read: web-facing) HTTP API which calls into underlying (read: non-web-facing) Thrift Services.

我正在构建一个基于前端（读取：面向网络）HTTP API 的分布式应用程序，该 API 调用底层（读取：非面向网络）Thrift 服务。

As an example, I may have:

例如，我可能有：

• authentication-service (contains the code for authentication)
• core-service (contains generated thrift sources and some common classes such as service discovery and initialization logic)

• 身份验证服务（包含身份验证代码）
• core-service（包含生成的thrift源和一些常见的类，如服务发现和初始化逻辑）

All of the individual services depend on core-services, as does the HTTP web-facing API. I have this as a multi-module project right now, but I would like each to be separate (and tracked in their own repositories - though I know I could still do this with a multi module build).

所有单个服务都依赖于核心服务，HTTP 面向 Web 的 API 也是如此。我现在将它作为一个多模块项目，但我希望每个项目都是独立的（并在他们自己的存储库中进行跟踪 - 尽管我知道我仍然可以通过多模块构建来做到这一点）。

tl;dr -

tl;博士 -

Is it a common build practice to have a module (core-service) which is individually built and then pushed to a maven repo (and then included as a jar in the other projects), or would it be better in this case to do a multi-module project?

有一个单独构建的模块（核心服务），然后推送到 Maven 存储库（然后作为 jar 包含在其他项目中）是一种常见的构建实践，还是在这种情况下最好做一个多模块项目？

回答by Nick Holt

Personally I try to avoid multi-module projects as, if you're using the Maven Release Plugin, you are locked into releasing all your modules together.

就我个人而言，我尽量避免多模块项目，因为如果您使用Maven Release Plugin，您将被锁定在一起发布所有模块。

While this may sound like a convenience the problem arises when you need to do bug fix release to one of the modules - you end up releasing all the modules, not just the module with the bug fix, incrementing their version even though they haven't changed.

虽然这听起来很方便，但当您需要对一个模块进行错误修复发布时就会出现问题 - 您最终会发布所有模块，而不仅仅是带有错误修复的模块，即使它们没有增加它们的版本改变了。

You also take a hit if you're running CI with multi-module projects - you're build typically runs over all modules from you root pom but if you're working in a particular module, you end up taking the hit of building those that haven't changed, in effect losing some of the benefits that the modularization was meant to provide.

如果您使用多模块项目运行 CI，您也会受到打击 - 您构建的构建通常运行在根 pom 中的所有模块上，但是如果您在特定模块中工作，您最终会受到构建这些模块的打击这并没有改变，实际上失去了模块化旨在提供的一些好处。

So, go with independent modules but, and this is the important bit, create a common 'dependency' pom used by each.

所以，使用独立的模块，但是，这是重要的一点，创建每个模块使用的公共“依赖”pom。

A 'dependency' pom is a pom that standardizes all the dependencies across your projects and is different in that those dependencies are specified in the dependencyManagementsection rather than the dependenciessection (it also sets up standard plugin config, etc). This allows your project poms to specify the dependency pom as their parent and then declare the dependencies they need minus the versions, which are picked up from the 'dependency' pom and thus standardized across your projects.

'dependency' pom 是一种标准化项目中所有依赖项的 pom，不同之处在于这些依赖项是在dependencyManagement部分而不是dependencies部分中指定的（它还设置了标准插件配置等）。这允许您的项目 pom 将依赖项 pom 指定为它们的父项，然后声明他们需要的依赖项减去版本，这些版本是从“依赖项”pom 中提取的，从而在您的项目中标准化。

If you are still concerned about being able to built everything, this can be achieved with a simple batch-file.

如果您仍然担心能够构建所有内容，这可以通过一个简单的批处理文件来实现。

回答by StanislavL

I would say multi-module project is better. In case of placing core service in the repository developers should care about versions. Developer1 needs the old service but Developer2 updates the service.

我会说多模块项目更好。如果将核心服务放在存储库中，开发人员应该关心版本。Developer1 需要旧服务，但 Developer2 更新服务。

Multiple branches also could be a problem.

多个分支也可能是一个问题。

回答by whaley

A multi-module build should be favored when all of the individual modules will have the same lifecycle as each other... in other words, when they are always released together, have their version numbers incremented together, etc. etc.

当所有单独的模块彼此具有相同的生命周期时，应该支持多模块构建……换句话说，当它们总是一起发布时，它们的版本号一起递增，等等。

A strong example of this in the OSS world is the apache camel project. For instance, all of the bundled components exist as individual modulesthat can be included separately in your project, but are tied to the same lifecycle as the camel core distribution.

在 OSS 世界中的一个很好的例子是apache camel 项目。例如，所有捆绑组件都作为单独的模块存在，可以单独包含在您的项目中，但与骆驼核心发行版绑定到相同的生命周期。

Maven multi-module builds allow for some conveniences when it comes down to putting your projects in CI or loading them in IDEs for instance but, generally speaking, if all of the individual modules do not share the same lifecycle, then a multi-module project is not a great fit

Maven 多模块构建为将项目放入 CI 或将它们加载到 IDE 中提供了一些便利，但一般来说，如果所有单个模块不共享相同的生命周期，那么多模块项目不太合适

回答by Nicola Musatti

In principle it is always better to have your projects evolve as independently as possible. However this is more an organizational issue rather than a technical one. When all is said and done your project structure should be consistent with your organization.

原则上，让您的项目尽可能独立发展总是更好的。然而，这更像是一个组织问题，而不是一个技术问题。当一切都完成后，您的项目结构应该与您的组织保持一致。

This boils down to keeping projects separate and have depending projects manage dependencies by means of a local repository manager if they are either maintained by different people or it makes sense to release them at different times. Otherwise you're probably better off with a multi-module project structure.

这归结为保持项目独立，并且如果依赖项目由不同的人维护或者在不同时间发布它们是有意义的，那么依赖的项目通过本地存储库管理器管理依赖项。否则，使用多模块项目结构可能会更好。

In our project we went for a sort of an in-between choice: we do have a multi-module structure, but all the projects reside in independent Subversion repositories, so that they can be branched separately, and we use the aggregator project to choose how to mix and match projects from different branches by means of svn:externalsin order to create customized releases for specific customers.

在我们的项目中，我们进行了一种中间选择：我们确实有一个多模块结构，但所有项目都驻留在独立的 Subversion 存储库中，以便它们可以单独分支，我们使用聚合器项目来选择如何混合和匹配来自不同分支的项目svn:externals，以便为特定客户创建定制版本。

The downside is that maintaining a similar structure is complicated and time-consuming. We have developed a significant amount of scripts to partly automate these tasks. This is particularly burdensome because the Maven release pluginis not capable of dealing with modules hooked by means of Subversion externals.

缺点是维护类似的结构既复杂又耗时。我们开发了大量脚本来部分自动化这些任务。这是特别繁重的，因为Maven release plugin它无法处理通过 Subversion 外部挂钩的模块。