我们设置了一个非常模块化的 Maven pom,其中常见的 jar 和特定的 jar 都被捆绑到 war 和 Ear 中。由于 70 多个模块之间有如此多的重用,我们不使用多模块,每个模块都可以并且确实有自己的生命周期,并且可以独立于任何其他模块发布。
所有模块都继承自各个父pom,最终每个pom都继承自一个主POM,其中定义了所有外部版本(例如spring)和公共(public)本地模块版本。
在我们发布版本之前,这一切正常。如果主 POM 需要更改(偶尔会这样做),则所有 pom 都需要以一种或另一种方式更新。我知道 Maven 版本插件可以使用最新的 SNAPSHOT 版本等更新特定的 POM,但这仅适用于单个 POM 级别。
我们希望能够在发布完成后迭代地更改所有 pom。
我们不使用多模块 POM,并且无法更改我们的构建过程以使用此机制。
我已阅读过相关内容,最接近问题的地方就在这里。 https://stackoverflow.com/a/3615417/1279002
编写 shell 脚本似乎是一种解决方案,但我们有 Windows 和 Linux 混合的开发和构建系统。我相信其他人会解决这个问题。谁能告诉我他们是如何解决这个问题的?
最佳答案
在类似的设置中,我的所有父 POM 始终保持在 1.0.0-SNAPSHOT
并在父 POM 中设置各种属性来跟踪内部模块版本号(因此此设置现在将依赖项管理版本和自定义模块版本[通过属性]集中到父 POM 中)。
因此,如果我需要更新对某些 com.myco:module-x
的引用,我可以这样做:
- 编辑适当的父 POM 并设置
<module-x.version>1.2.3</module-x.version>
属性为新值 - 重建/安装父 POM
- 重建目标最终应用程序(ear、war、jar 应用程序等)。
在哪里module-x
的 POM 它的定义可能是这样的:
<groupId>com.myco</groupId>
<artifactId>module-x</artifactId>
<version>${module-x.version}</version>
以及任何引用 com.myco:module-x
的 POM通过${module-x.version}
引用它也是如此。
此时,应用程序的构建将拾取父 POM 中的更改,以及它对父 POM 中定义的任何属性的任何引用。
在“中间人”模块需要何时/如何重建方面存在一些微妙的细微差别......
但我真的不相信这里有什么 Elixir 。
我们采用的方法效果非常好,再加上 Jenkins,每当父 POM 发生更改时,就可以自动重建具有相互依赖关系的模块。
这样做的好处是,除了父 POM 之外,您很少需要修改任何内容。中间人模块和应用程序 POM 不需要更新即可获取新版本号等。
最大的警告是,同一版本的给定模块的两次重建可能会导致不同的 Artifact ,例如:
- module-x 依赖于 module-y:1.2.3
- 已构建 module-x(使用引用 module-y:1.2.3 的 MANIFEST 创建 jar)
- 父 POM 修改为设置
<module-y.version>1.2.4</module-y.version>
- 重建 module-y 以创建 1.2.4 Artifact
- 已构建 module-x(使用引用 module-y:1.2.4 的 MANIFEST 创建 jar)
但请注意,#2 和 #5 都使用 module-x 的相同版本构建了 module-x,但有两个不同的嵌入式 MANIFEST 引用了不同的 module-y 版本。
我们通过使用 Jenkins CI 服务器自动化所有依赖模块来克服这种细微差别
关于java - 如何更新 Maven POM 中的版本号,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28280090/