2

在进行快照/发布时，依赖项的编号/版本控制策略是什么？

一个由 15 名开发人员组成的团队，20 个 Maven 父项目 = 总共 70 多个 POM，包括子模块 POM。目前有很多依赖关系，这 70 个依赖项中的大多数依赖于其中一个。

过去的：

所有 POMS 都有1.0.0-SNAPSHOT其版本和依赖项标签。它使用 .它上传到 Nexus 存储库mvn deploy。

当下：

mvn release我们最近开始做。所以现在所有 20 个父 POM1.0.1-SNAPSHOT和它们的发布版本1.0.0都位于 Nexus 中。所有<dependencies>标签现在都指向1.0.0

问题：

开发人员不想指向发布版本。他们需要来自同行的前沿开发版本1.0.X-SNAPSHOT，无论它是否不稳定。

SCM只想指向RELEASE版本，因为他必须mvn release每周执行一次，这将失败，因为它指向快照版本。

问题：

现在我知道了版本插件，但问题是，我在 POM 中放了什么，以便双方都通过运行自己的mvn versions:命令版本感到满意。最好 POM 应该指向 SNAPSHOTS 以便 15 人满意，并且当 SCM 发布时，他可以运行 amvn versions:something并且所有内容都转换为RELEASE版本来代替SNAPSHOTS. 然后返回给开发人员的 SNAPSHOTS。

4

1 回答 1

3

我将其作为答案，尽管目前这还不是很有效的答案。

当我completionGoals在 Maven 发布插件中添加配置选项时，我的目标是启用开发使用版本范围的工作流程，但该版本将仅固定到具体版本。

添加到版本 Maven 插件的启用目标之一就是versions:resolve-ranges目标。缺少的是一种在之后再次解开这些范围的方法。

在我们再次需要它之前，我们真的没有任何安全的地方来存储发布插件不会反对或清理的原始范围。

我想到的最接近的解决方案是在包含版本范围的版本旁边注入XML PIpom.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您有（尚未实现的）versions-maven-plugin 目标，该目标删除 XML PI 并将范围放回原处。

目前有许多问题阻止了这一点：

  • 不确定 Maven 发布插件的 pom 重写是否会删除 XML PI（需要测试确认）

  • versions-maven-plugin 中的 XML 解析库充其量是 hacky，需要更好的解决方案来启用 XML PI 注入

  • 我的儿子需要关注，我很少有时间来处理这些问题。

但是，您也许可以一起拼凑一些东西。

  1. 设置completionGoals为类似versions:use-next-snapshots versions:commit

  2. 像这样运行你的版本mvn versions:use-releases versions:commit scm:commit release:prepare release:perform install

那么应该发生什么：

  • 我们将-SNAPSHOTs 切换到发布

  • 我们将更改提交给 SCM

  • 我们开始发布准备

  • 当pom.xml转换为下一个开发版本时，我们还推进了依赖项（利用我们所有的依赖项都有完全相同的命令（install末尾带有）的事实，因此它们的下一个-SNAPSHOT已经在本地存储库中，因此它们将得到高级自动为我们（理论上）），我们依靠release:prepare为我们提交更改。

  • 释放正常执行

  • 我们将下一个开发安装-SNAPSHOT到本地 repo 中，以便所有下游项目在运行时都会更新其版本versions:use-next-snapshots

以上内容容易出错......如果我可以为您提供基于版本范围的解决方案，我会更喜欢，但是，现在这是我能看到的最好的解决方案。

于 2013-02-01T15:17:30.240 回答