我们有一个非常模块化的Maven pom设置,常见的罐子和特定的罐子都捆绑在战争和耳朵里。由于在70多个模块中有太多的重用,我们不使用多模块,每个模块都可以并且确实有自己的生命周期,并且可以独立于任何其他模块发布。
所有模块都继承自各种父pom,最终每个pom都继承自主POM,其中定义了所有外部版本(如spring和公共本地模块版本)。
在我们发布之前,这个工作正常。如果主POM需要进行更改,偶尔会进行更改,所有 poms需要以这种或那种方式进行更新。我知道maven版本插件可以使用最新的SNAPSHOT版本等更新特定的POM,但这仅适用于单个POM级别。
我们希望能够在迭代完成发布后更改所有poms。
我们不使用多模块POM,也无法更改构建过程以使用此机制。
我已经阅读了SO,问题就在这里。 https://stackoverflow.com/a/3615417/1279002
编写shell脚本似乎是一个解决方案,但我们有Windows和Linux混合的开发和构建系统。我相信其他人也会解决这个问题。任何人都可以建议他们如何解决这个问题?
答案 0 :(得分:1)
在类似的设置中,我的所有父POM始终保持在1.0.0-SNAPSHOT
并在父POM中设置各种属性以跟踪内部模块版本号(因此此设置现在集中了依赖关系管理版本和自定义模块版本[通过属性]进入父POM)。
因此,如果我需要更新对某些com.myco:module-x
的引用,我可以这样做:
<module-x.version>1.2.3</module-x.version>
属性设置为新值在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中定义的任何属性的任何引用。
在“中间人”模块需要重建的时间/方式方面有一些微妙的细微差别......
但我真的不相信这里有任何银弹。
我们采用的方法非常有效,再加上Jenkins可以在父POM发生变化时自动重建具有相互依赖性的模块。
这里的好处是你很少需要修改除父POM之外的任何东西。中间人模块和应用程序POM不需要更新以获取新的版本号等。
最大的警告是,在同一版本中给定模块的两次重建可能会导致不同的工件,例如:
<module-y.version>1.2.4</module-y.version>
但请注意,#2和#5都为module-x构建了模块-x和相同版本,但是有两个不同的嵌入式MANIFEST引用了不同的模块-y版本。
我们通过使用Jenkins CI服务器自动化所有相关模块来克服这种细微差别