创建发布版本后如何管理 Maven 依赖工件答案

【问题标题】：How to manage maven dependant artifacts after creating release versions创建发布版本后如何管理 Maven 依赖工件
【发布时间】：2019-04-18 17:39:52
【问题描述】：

我们正在使用发布插件将快照转换为发布，但快照已作为依赖项添加到其他项目中。我们是否需要更新每个项目 pom 以使用新版本。

例如：ArtifactA 包含在 ArtifactB 中，

ArtifactA 包含在 ArtifactC 中

ArtifactB 和 ArtifactC 包含在 Artifact D 中

是否有另一种方法可以推送依赖版本来代替快照

[我们使用 Jenkins 构建并推送到 Nexus]

【问题讨论】：

【解决方案1】：

我们的构建服务器运行versions:use-releases，然后在构建之前向 SVN 提交。这会将所有 SNAPSHOT 版本替换为其各自的发布版本（如果存在）。

【讨论】：

可能这是一个很好的答案，但我不知道构建服务器设置。我们的模型：创建功能分支并进行更改，使用 jenkins 作业来构建和部署 [无 nexus 推送]。测试功能。如果一切正常，将触发构建作业的分支与部署目标合并。这会在 Nexus 中创建工件。显然这是一个快照。现在我们创建了一个新的 jenkins 工作，其发布目标是转换该项目，这意味着我必须为我的 n 个项目创建“n”个工作。有替代/简单的解决方案吗？
如果您在 Jenkins 中运行脚本化或声明性管道，您可以在其中定义不同的步骤，包括您要调用的每个 maven 目标的步骤。
Thanks.mvn 版本：使用发布。我找到了这个链接mojohaus.org/versions-maven-plugin/examples/use-releases.html

【解决方案2】：

一种不那么繁琐的版本处理方式 - 继续使用快照。从技术上讲，快照没有任何问题，也没有必要将它们更改为发布版本。只是不要使用带有SNAPSHOT 后缀的版本 - 使用已解析的快照（带有时间戳和内部版本号）。

至于依赖项——通常在发布后不需要立即更改版本。只有当客户需要更新时，他们才应该手动更改为较新的版本。

如果我们将远程 API 及其客户端库视为依赖项 - 此类远程 API 需要保持向后兼容性，以便为其他人提供一些升级时间。

【讨论】：