创建多模块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） - 战争（2.5。 3-SNAPSHOT）< - 3在最后，因为C有2个重新发布和一个，并在每个模块发布后发布为简单起见

我们决定管理主pom中的神器版本，所以我们不在发布一个模块后，不需要更新每个artefact的依赖版本

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

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

感谢主POM的dependencyManagement部分，如果我建了战争模块，它会自动选择模块A.

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

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

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

这种szenario是一个愚蠢的想法？是否有替代方案来开发和维护这样的大型多模块应用程序？由于应用程序很大，客户端应用程序必须加载更新的模块版本，因此只需要将所有版本同步并在整个项目中使用发布插件即可。我们的一些客户的连接速度非常慢，因此每次推出所有模块都会让他们真的很不高兴。

帮助非常感谢，

克里斯

Answer 1

那么我想出了一个解决我的问题。它是一个小型的releaste-plugin补丁和一个Jenkins Plugin的组合，用于处理需要的非常强大的命令行配置。释放过程中

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

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

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

Answer 2

首先，我们需要认识到的版本号是很重要的，而对于依赖管理的重要，完全是任意的。至少，版本号的形式是任意的（是的，我知道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 3

昨天晚上我意识到我在我的问题中构建的构建还有另一个主要问题：模块彼此之间存在差异，这些将不会由release插件处理。这些SNAPSHOT依赖会导致插件失败（这是很好的）。

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

现在发布将需要执行以下步骤： - 将versions-rel和versions-dev更新为新版本。 - 提交 - 标签 - 运行释放：执行发布插件的目标

还有一两件事，可能导致问题：假设所有模块已被修改，但只有一个应该被包含在一个新的版本，那么这种方法也会重新部署所有的模块，即使是我不想发布的模块。这会导致更改后的版本与之前发布的版本部署在同一版本中。现在我可以通过不发布主项目来避免这种情况，而只是单个模块。但是，如果只能部署那些未全部部署的版本，则会使发布过程变得更容易。

任何建议，异议，事情我forgott？

Chris