在多模块Maven项目中更新模块版本的最佳策略是什么

Question

鉴于：多模块Maven项目

任务：每次发布后更新版本

我看到了两种不同的策略：

策略1 - 整个更新：更新所有模块的版本，尽管事实上是否有更新

策略2 - 简约更新：仅更新实际受影响的模块版本

假设我们有以下项目结构：

root
---dao
---domain
---web
   ---site1
   ---site2
---processors
    ---processor1
        ---processor1Service
        ---processor1Util
        ---processor1Tests
    ---processor2
        ---processor2Service
        ---processor2Util
        ---processor2Tests
---simulators
    ---simulator1
        ---simulator1Service
        ---simulator1Util
        ---simulator1Tests
    ---simulator2
        ---simulator2Service
        ---simulator2Util
        ---simulator2Tests
---etc

所有父pom都有包装类型 - pom。所有最终模块都有资源生成类型 - jar，war，sar等。 Root pom包含 dependencyManagement 部分，其中列出了所有子模块。

---

策略1：

• 发布经理RM（或任何人）合并来自“功能”的更新 分支（S）
• 所有持续整合的东西都在发生（让他们没问题）
• RM在根
上调用mvn release：versionUpdate -DsetVersion = 1.2
• 完成

策略2：

• RM合并来自“功能”分支的更新

• 所有持续整合的事情都在发生（让他们没问题）

• RM使用subversion工具（git，svn，无论如何）检查实际受影响的模块
• RM手动增加受影响模块的版本
• 完成

---

策略1：

好处：

1. 没有人工输入（版本号除外）
2. pom配置很简单且统一，只能在root pom上使用dependencyManagement部分处理
3. 所有模块的单个版本，因此没有动物园 模块版本
4. 无需依赖必须检查位置的外部工具 实际更新（甚至更糟 - 依赖于RM注意力）
5. 开发人员不限于进行任何与之无关的更改 他们的模块（例如，如果你添加新的行或者不需要害怕 在IDE中意外运行自动格式化工具）

缺点：

1. 将是实际上没有的模块的更新版本 受影响 - 因此可能出现硬盘空间问题

策略2：

好处：

1. 将是实际更新的模块的更新版本

缺点：

1. 版本的动物园。 dao_1.2取决于domain_1.52，两者都取决于 etc_1.639模块
2. 手动输入
3. 必须检查实际更新的外部工具的依赖性

请分享您的意见。如何在大型项目中处理此问题，例如springframework的

Answer 1

就个人而言，我绝对会选择你的策略1.这就是我所工作的公司使用的策略。您提到的硬盘空间或升级模块版本不需要升级的副作用与“版本动物园”相比是次要问题。

在您使用OSGI架构的情况下，只有我会投票选择您的策略2，这需要非常精确的模块版本控制策略，如果您一次升级所有版本，它将毁掉OSGI的最大好处（热门 - 仅部署需要更新的模块/子模块。

我还建议你看看http://java.dzone.com/articles/why-i-never-use-maven-release，它提供了如何在多模块maven项目中升级版本以及如何在任何CVS中跟踪的良好提示