Maven父POM与不同子版本

Question

我们的应用程序中有多个模块，每个模块都有自己的版本，并依赖于其他模块（外部组织）。它们都有一个父POM，其版本独立于子模块的版本。

当这些模块之一发生变化时，它们将被转换为快照。

以下是一个示例：

Parent v14.0
- module1 v1.5.0
    - dependency1(module2 v15.0.0)
    - dependency2(external-jar v12.0.1)
- module2 v15.0.0
- module3 v3.1.0

如果module2发生变化，则module2的版本将变为v15.0-SNAPSHOT，module1变成v1.5-SNAPSHOT。父类保持不变。

之所以不在父模块和子模块上使用相同的版本号，是因为我们希望将更新限制在某些模块上，而不影响其他模块的版本。

这种设计已经存在很长时间了，并且有几个bash脚本来支持更新，虽然它们不能处理所有情况。无论如何，我们没有一个一键发布流程，并且我们觉得用这种方法还远离此目标。

我们不知道如何说服管理层采用所有模块统一版本的方法。您对以上内容有什么看法？您是否曾经遇到过使用以上结构的项目，以及它的运行状况如何？

谢谢！

- yang-spirit

Answer 1

我以前处理过这样的情况。拥有分散的版本实际上有益处，特别是在您的产品由大量模块组成的情况下，原因如下：

• 如果只更改了一小部分模块（根据我的观察，几乎总是这种情况），则不必将它们全部发布。

• 对于自上次发布以来未更改的代码，不必在版本控制中创建不必要的标签。

• 不必浪费大量时间发布不需要发布的模块。

• 您知道哪些模块在发布中发生了变化，这在您需要调查复杂的错误时非常有帮助，尤其是那些看起来已经存在一段时间的错误。

• 您可以在完整产品实际发布日期之前实际上发布某些模块/聚合器，从而提供更多的测试时间和给定产品部分的完整感。

• 您可以更轻松地进行功能分支发布，并以更好的方式实现持续交付。

• 您可以在多个开发分支之间重复使用相同的代码，而不必担心该分支版本是否与您的分支版本匹配（或者至少混淆较少）。

我们最终做的是：

• 提取一个父级或一组没有子模块的父级。

• 尽可能使用固定版本的父级。这有点棘手，因为您必须更改继承它的所有模块，但最终会提高稳定性。

• 将其版本独立于其余部分的每个模块提取到单独的模块中。

• 将必须始终一起移动版本的模块集合提取到聚合器中。

• 在 CI 服务器中创建可以进行发布或手动发布这些模块的作业。

• 使用 versions-maven-plugin。

我认为，对于项目和公司的发展原则来说，使用分散的版本更具成熟性。我必须承认，在开始时我非常不愿意采用这种方法。您可能不会立即意识到或理解其好处，但通过一些实践和适当的设置，您将开始看到优点。我并不是说没有缺点，例如增加父级的版本或必须知道在哪些模块中增加了您的模块的版本。

根据我的经验，一旦您习惯了使用它，最终该模块实际上运行得更好。

- carlspring

---

“将版本必须始终一起移动的模块集提取到聚合器中” - 如何使用Maven实现？什么是聚合器？ - yang-spirit

聚合器是一个具有<modules/>的Maven项目。它的打包类型只是pom。在您的情况下，您似乎有一个父聚合器。我建议不要采用这种方法，因为它不够灵活。例如，您可以拥有一个聚合器，其中包含10个模块，其中一部分具有一个父级，另一部分具有另一个父级（扩展第一个父级）。这对于为聚合器中的不同模块集定义不同的插件规则或依赖项集是很常见的。 - carlspring

你能否描述一下如何以分散的方式使用版本插件？非常感谢！ - yang-spirit

请查看我链接的目标概述页面。那里有很好的解释，以及一系列目标列表，如 set、use-releases、use-next-releases、use-next-snapshots、use-latest-releases、use-latest-snapshots... - carlspring

是的，maven-release-plugin 与这种方法很好地配合使用。如果您有一个聚合器，它将要求您为每个模块提供下一个版本。这就是为什么您应该尝试将可以独立版本的模块分开，并将使用相同版本的模块分组的原因。 - carlspring

Answer 2

根据我的经验：我们在任何地方尝试过这种方法，最终都失败了。

Maven虽然支持这种方法，但由于额外的工作量，不建议使用。

我在选择使用单独项目或多模块结构时，尝试使用以下标准：

• 如果所有项目具有相同的发布周期，则将它们放在一个共同的多模块结构中。在这种情况下，我会给它们相同的版本并一起发布。
• 如果项目的一部分被不同的其他项目（组织项目）使用，则我总是将它们拆分并赋予它们单独的生命周期和版本。
• 如果我的项目的某个部分稳定下来，我会将其拆分并赋予它单独的生命周期（Maven重构）。

采用不同的方法通常会导致自制解决方案，既不易扩展，也不易维护。

希望能对您有所帮助。

- blackbuild