在多模块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等。根pom包含dependencyManagement部分，其中列出了所有子模块。

战略1：

• 发布管理器RM (或其他人)合并了来自“特性”分支的更新
• 所有连续集成的事情都在发生(让他们没事吧)
• RM调用mvn发行版:根目录上的版本更新-DsetVersion=1.2
• 完成

战略2：

• RM合并来自“功能”分支的更新。
• 所有连续集成的事情都在发生(让他们没事吧)
• RM检查实际使用subversion工具(git、svn等)受影响的模块。
• RM手动增加受影响模块的版本
• 完成

策略1:

利益

1. 没有人工输入(除了版本号外)
2. pom配置简单且统一，只能在根pom上使用dependencyManagement部分进行处理。
3. 一个单一版本的所有模块，因此没有动物园的模块版本
4. 不需要依赖外部工具，这些工具必须检查实际更新的位置(或者更糟的是--依赖于RM的关注)。
5. 开发人员不受限制进行与其模块无关的任何更改(f.e。如果在IDE中添加新行或意外运行自动格式化工具，则无需担心)

缺点：

1. 将更新实际上未受影响的模块版本--因此，可能会出现HDD空间问题。

策略2:

福利：

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

缺点：

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

请分享你的意见。这个问题是如何在像handled框架这样的大型项目中处理的

Answer 1

就我个人而言，我绝对支持你的战略1。这是我工作的公司所采用的战略。您提到的不需要升级的HDD空间或升级模块版本的副作用与“版本动物园”相比是次要问题。

只有我会投票给您的策略2号，如果您使用的是OSGI架构，这需要非常精确的模块版本策略，如果您立即升级所有版本，它将破坏OSGI (只需要更新的模块/子模块热部署)的巨大好处。

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