我目前正致力于优化多模块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）＆lt; - 3结尾，因为C有2个重新发布和A 1，并且为了简单起见，在每个模块发布后发布。
我们决定在主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”范围将其导入到主poms dependencyManagement中。
这种szenario是一个愚蠢的想法吗？是否有开发和维护这样的大型多模块应用程序的替代方案？简单地使用整个项目中的发布插件使所有版本同步并不是一个选项，因为应用程序很大并且客户端应用程序必须加载更新的模块版本。我们的一些客户的连接速度非常慢，因此每次推出所有模块都会让他们感到非常不满。
非常感谢，
克里斯
答案 0 :(得分：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也是你的朋友。
最终发布的工作流程如下：
2.5.5-SNAPSHOT开始。mvn versions:set -DnewVersion 2.5.5。mvn deploy -Prelease激活您的“发布配置文件”，将内部版本号添加到工件finalName。mvn versions:set -DnewVersion 2.5.5-SNAPSHOT。当你有一个真正的“主要”版本时，增加到版本2.5.6,2.6.0等。
祝你好运！答案 1 :(得分：1)
我想出了解决问题的方法。它是一个小型的重新插件补丁和一个Jenkins插件的混合，用于处理所需的非常强大的命令行配置。
Jenkins插件的描述： https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
答案 2 :(得分：0)
昨晚我意识到我在我的问题中提出的构建还有另一个主要问题：模块彼此之间存在差异，这些不会由发布插件处理。这些SNAPSHOT依赖项会使插件失败（这很好）。
所以我有另一个想法可以解决我的问题： 我将创建两个maven pom工件“versions-dev”和“versions-rel”，其中包含一个dependencyManagement部分，用于定义dev和rel版本。在我的主pom中，我现在将创建两个配置文件“development”（默认激活）和“release”，必须手动激活。这些概要文件包含dependencyManagement部分，每个部分都使用范围“import”导入相应版本-pom工件的dependencyManagement。
现在发布版本必须执行以下步骤： - 将versions-rel和versions-dev更新为新版本。 - 提交 - 标签 - 运行发布：执行发布插件的目标
还有一件事可能会导致问题：假设所有模块都已修改，但只有一个模块应该包含在新版本中，那么这种方法也会重新部署所有模块，即使是那些我没做过的模块。我想发布。这将导致使用与先前发布的版本相同的版本部署更改的版本。现在我可以通过不释放主项目来避免这种情况，但只能释放单个模块。但是，如果只能部署那些尚未完全部署的版本，那么它将使发布过程变得更加容易。
有任何建议，异议，我原谅的事情吗？
克里斯