创建一个多模块 Maven 构建和独立发布单个模块？

Question

我目前正在优化多模块 maven 项目的 maven 构建。该项目由大约 90 个 Maven 模块组成。一般来说，有一些交叉库构成核心，然后大约有 15 个“应用程序模块”构成整个应用程序（然后将其部署为 WAR）

现在通常整个项目都有一个主要版本“2.5”，所以当一个新的主要版本完成时，所有“应用程序模块”都具有相同的版本“2.5.0”。到目前为止，一切都很好。

如果某个模块存在需要修复或改进的错误，则应发布该“应用程序模块”的新版本。例如，模块 A 修复了一个错误，那么 A.jar 的版本应该是“2.5.1”，而其余的应该仍然是“2.5.0”。

父母（2.5.0-SNAPSHOT - 模块 A (2.5.1-SNAPSHOT) - 模块 B (2.5.0-SNAPSHOT) - 模块 C (2.5.2-SNAPSHOT) - War (2.5.3-SNAPSHOT)

我们决定在主 pom 中管理工件版本，因此我们不需要在发布一个模块后更新每个工件的依赖版本。

所以现在每当更新的“应用程序模块”准备就绪时，我们使用 maven 发布插件来执行该模块的发布（我们发布的是一个模块，而不是整个项目）。因此，假设我们在 2.5.4 版本中发布模块 A，导致 A.jar 被部署为 2.5.4 版本，并通过将模块代码更新为 2.5.5-SNAPSHOT 来完成。

完成此操作后，我们需要更新主 pom 中的版本，以便所有模块继续引用正确的版本。

感谢主 pom 的 dependencyManagement 部分，如果我构建 War 模块，它会自动选择模块 A 的新版本。

现在是棘手的部分：一旦所有模块都发布了，就应该发布新版本的 Web 应用程序。这应该包含所有未更改的模块以及刚刚发布的模块。我目前正在努力解决如何做到这一点。如果我依赖于父 poms 版本，则该版本将包含 SNAPSHOT 版本（所有一个版本增量都太高），这是我和发布插件不允许的。

解决这个困境的最佳方法是什么？

我有一个想法，将依赖管理外包给一个单独的 pom，然后使用“import”范围将其导入主 pom dependencyManagement。

这种情景是愚蠢的想法吗？是否有替代开发和维护这样的大型多模块应用程序的方法？简单地让所有版本同步并在整个项目上使用发布插件不是一种选择，因为应用程序很大并且客户端应用程序必须加载更新的模块版本。我们的一些客户的连接速度非常慢，因此每次推出所有模块都会让他们非常不高兴。

帮助不胜感激，

克里斯

Answer 1

首先，重要的是要认识到版本号虽然对依赖管理很重要，但完全是任意的。至少，版本号的形式是任意的（是的，我知道the syntax for Maven version ranges，我从未听说过有人使用它）。一些 OSS 项目完全避开“传统”版本号，仅使用 SVN 存储库版本或日期进行版本控制。

一种选择是没有“项目范围”的版本，而是允许您的每个组件具有不同的版本号。我觉得这是一个完全可以接受的解决方案。

另一种解决方案是使用快照依赖项发布。您不是“应该”这样做的，但没有什么能阻止您对快照版本进行硬编码（它非常冗长且带有时间戳）。无论如何，除了不可重复构建的幽灵之外什么都没有。

如果您必须让所有组件具有相同的版本号，我建议将内部版本号合并到项目版本的次要组件中。

在这种方法中，您可以利用Maven Build Number plugin 来区分版本中的增量版本，如以下问题所述：Can I set the project version with a buildnumber-maven-plugin?。

请注意，您只能在仅由您的构建服务器（或您的构建工程师）使用的“最终版本”配置文件中执行此操作。

Version Numbers plugin也是你的朋友。

最终的发布工作流程如下所示：

1. 从版本2.5.5-SNAPSHOT开始。
2. mvn versions:set -DnewVersion 2.5.5。
3. 提交并标记您的版本（或创建一个分支 - 无论您的策略是什么）。
4. mvn deploy -Prelease 激活您的“发布配置文件”，将内部版本号添加到工件 finalName。
5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT。
6. 提交您的“发布后”版本。

当您拥有真正的“主要”版本时，增加版本 2.5.6、2.6.0 等。

祝你好运！

Answer 2

昨晚我意识到我在我的问题中提出的构建还有另一个主要问题：模块之间存在依赖关系，并且这些不会由发布插件处理。这些 SNAPSHOT 依赖项会使插件失败（这很好）。

所以我刚刚有了另一个可能解决我的问题的想法： 我将创建两个 maven pom 工件“versions-dev”和“versions-rel”，其中包含定义 dev 和 rel 版本的 dependencyManagement 部分。在我的主 pom 中，我现在将创建两个配置文件“开发”（默认情况下处于活动状态）和必须手动激活的“发布”。这些配置文件包含一个dependencyManagement 部分，并且每个都使用范围“import”导入相应版本-pom 工件的dependencyManagement。

现在发布必须执行以下步骤： - 将versions-rel 和versions-dev 更新为新版本。 - 犯罪 - 标签 - 运行发布插件的发布：执行目标

还有一件事可能会导致问题：假设所有模块都已修改，但新版本中应该只包含一个，那么这种方法也会重新部署所有模块，甚至是我没有部署的模块。不想释放。这将导致使用与先前发布的版本相同的版本来部署更改的版本。现在我可以通过不发布主项目而只发布单个模块来避免这种情况。但是，如果可以只部署那些尚未部署的版本，那么发布过程会容易得多。

有什么建议、反对意见、我忘记的事情吗？

克里斯

Answer 3

好吧，我想出了一个解决我的问题的方法。它是一个小的发布插件补丁和一个 Jenkins 插件的组合，用于处理所需的相当密集的命令行配置。

发布流程说明： https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

Jenkins 插件说明： https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

插件代码： https://github.com/chrisdutz/jenkins-release-plugin