执行快照/发布时依赖项的编号/版本控制策略是什么?
由15名开发人员组成的团队,20个Maven父项目=总共70多个POM,包括子模块POM。目前存在许多依赖关系,其中大多数70依赖于一个或另一个。
所有POMS都有1.0.0-SNAPSHOT
个版本,也有依赖关系标记。它会被mvn deploy
上传到Nexus repo。
我们最近开始做mvn release
。所以所有20个父POM现在都是1.0.1-SNAPSHOT
,而版本1.0.0
的所有版本都存在于Nexus.All <dependencies>
标签现在指向1.0.0
开发人员不希望指向发布版本。无论是否不稳定,他们都需要来自同行的前沿开发版本1.0.X-SNAPSHOT
。
SCM 只想指向RELEASE
个版本,因为他必须每周执行一次mvn release
,因为它指向快照版本会失败。
现在我知道了version plugin,但问题是,我在POM中放了什么,这样双方都可以通过运行自己版本的mvn versions:
命令来满足。优选地,POM应该指向SNAPSHOTS,因此15个人感到高兴,并且当SCM执行发布时,他可以运行mvn versions:something
并且所有内容都将转换为RELEASE
版本来代替SNAPSHOTS
。然后回到开发人员的SNAPSHOTS。
答案 0 :(得分:3)
我将此作为答案,尽管目前这还不是很有效的答案。
当我在Maven Release Plugin中添加completionGoals
配置选项时,我的目标是启用开发使用版本范围的工作流程,但该版本将仅固定到具体版本。
添加到Versions Maven插件的其中一个启用目标是versions:resolve-ranges
目标。缺少的是一种在之后再次解决这些范围的方法。
在我们再次需要之前,我们并没有安全地存放发布插件不会反对或清理的原始范围。
我想到的最接近的解决方案是在包含版本范围的版本旁边注入XML PI ...在这种情况下,pom.xml
将会转换自,例如
<project>
...
<dependencies>
...
<dependency>
<groupId>com.foo.bar</groupId>
<artifactId>manchu</artifactId>
<version>[1.2.3,2.0)</version>
</dependency?
...
</dependencies>
...
</project>
到
<project>
...
<dependencies>
...
<dependency>
<groupId>com.foo.bar</groupId>
<artifactId>manchu</artifactId>
<version>1.5.7</version>
<?versions-maven-plugin allowed-version-range="[1.2.3,2.0)"?>
</dependency?
...
</dependencies>
...
</project>
确保preparationGoals
包含versions:resolve-ranges
目标...(注意:版本插件可能需要派遣第三个Maven来解决缺少pom.xml
重新加载的问题让clean verify
有意义,尽管resolve-ranges
应该在构建正在使用的确切版本中解析,所以它不应该是一个问题。)
然后在completionGoals
中,你有(尚未实现的)版本-maven-plugin目标,删除XML PI并将范围放回原位。
目前存在许多阻止这种情况的问题:
不确定Maven Release Plugin的pom重写是否会删除XML PI(需要测试确认)
versions-maven-plugin中的XML解析库充其量只是hacky,需要更好的解决方案来启用XML PI注入
我的儿子需要注意,只留下很少的时间来处理这些问题。
但是,你可以将所有东西放在一起。
将completionGoals
设置为versions:use-next-snapshots versions:commit
像mvn versions:use-releases versions:commit scm:commit release:prepare release:perform install
那会发生什么:
我们将-SNAPSHOT
切换为发布
我们将更改提交给SCM
我们开始发布准备
当pom.xml
转换为下一个开发版本时,我们也推进了依赖关系(使用所有依赖关系具有完全相同的命令的事实(最后使用install
) )所以他们的下一个-SNAPSHOT
已经在本地存储库中了,所以他们将为我们自动(在理论中)并且我们依赖于{{1为我们提交更改。
发布正常执行
我们将下一个开发release:prepare
安装到本地仓库中,以便所有下游项目在运行时都会更新其版本-SNAPSHOT
以上内容有点容易出错......如果我能为您提供基于版本范围的解决方案,我会更喜欢,但是,现在这是我能看到的最佳解决方案。