9

我目前正在优化多模块 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) - 战争 (2.5.3-SNAPSHOT) <-- 3最后，因为 C 有 2 个重新发布，而 A 有一个，并且为了简单起见，在每个模块发布后发布。

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

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

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

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

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

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

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

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

非常感谢帮助，

克里斯

4

3 回答 3

2

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

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

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

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

在这种方法中，您利用Maven Build Number 插件来区分版本中的增量版本，如以下问题所述：我可以使用 buildnumber-maven-plugin 设置项目版本吗？.

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

版本号插件也是你的朋友。

最终的发布工作流程将类似于以下内容：

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

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

祝你好运！

于 2012-10-11T17:45:22.547 回答
1

好吧，我想出了一个解决我的问题的方法。它是一个小的发布插件补丁和一个 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

于 2013-09-29T18:01:18.923 回答
0

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

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

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

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

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

克里斯

于 2012-10-12T07:05:39.857 回答