什么时候应该在项目生命周期中使用 mvn release？答案

【问题标题】：When should mvn release be used in the project lifecycle?什么时候应该在项目生命周期中使用 mvn release？
【发布时间】：2011-08-31 21:00:59
【问题描述】：

澄清问题：

我正在寻找既定的最佳做法或已知做法的利弊分析
我的意思是项目生命周期：部署到预集成、集成、QA、预生产和生产环境。

对于某些上下文：我们的项目每周都会部署到集成和 QA，目前我们为每个集成部署创建一个新版本，但这感觉不对。它导致每周更新所有 pom，破坏开发级别的依赖关系，迫使每个开发人员刷新他们的 eclipse 配置。我们有很大的工作空间，而 Eclipse 不能很好地处理刷新，因此浪费了很多时间。

我对 maven 发布约定并不太熟悉，也无法找到关于应用程序生命周期点何时应该使用 mvn release 的约定。

如果我们现在使用的模式被接受/正确/确立，我会有另一个问题:)

【问题讨论】：

我没有忘记这个问题，在生命周期中实施更改并获得利弊回报需要一些时间，一旦我接受答案。

标签： java maven release maven-release-plugin alm

【解决方案1】：

我用来避免 Eclipse 开发级别依赖项更新问题的方法是保持相关主干或分支版本号不变，直到版本变得重要为止。通过这种方式，您可以对 QA 等进行正确标记/版本化的发布，以便您可以追溯问题，但不需要开发人员更新依赖项。为此，我使用以下命令，但覆盖版本号以获取所需的版本号，但重新输入当前快照版本作为新快照版本：

mvn release:prepare -DautoVersionSubmodules=true

附：我有一个图表可以证明这一点，但不幸的是，这个论坛没有足够的权利来附上它。如果有人可以方便附加，我会很乐意提供。

P.P.S 也许现在...

还要注意对早期分支 (2.1) 和晚期分支 (2.2) 的支持。

【讨论】：

我对图表很感兴趣 :) 我支持你，但我不确定它会提供足够的权利。同时，您可以通过我在 Google 邮件域中的 stackoverflow 用户名 dot helou 给我发送电子邮件。
参考 Ed Staub 上面关于重新提交 poms 的评论，使用我在此处描述的方法，您确实将修改后的 pom 检查到源代码控制中，即您只需让 Maven 做这件事。它将提交并标记版本化的 pom，然后使用原始快照版本重新提交 pom。因此，开发人员在进行更新时会看到新的 pom，但版本号保持不变......
... 不需要 'mvn eclipse:eclipse' 尽管如果有相关的 pom 更改确实需要传达给团队（或者可以从源代码控制历史记录中观察为不属于自动 Maven 提交的 pom 更改）。

【解决方案2】：

在我们的商店中，我们在 SVN 中的所有 POM 都有<version>9999-SNAPSHOT</version>（用于它们自己的版本以及内部依赖项）。这永远不会改变。

在构建期间，我们有一个简单的 ant build.xml，它将版本号（在 maven 之外建立）作为 -Dversion=... 参数，并且简单地这样做：

<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/> <artifact:mvn ... />

该更改在构建过程的工作副本中是本地的——它从未签入到版本控制中。

这样，所有发布版本都有一个“真实的”版本号，但实际上开发人员不必处理版本号。

正如您在问题中所说，上述内容强调不是执行此操作的正确方法，但自从我们采用 maven 以来，它在 ~9 mos 对我们来说效果很好。我们有数十个 maven 模块，所有这些模块都在 QA/发布过程中步调一致。

这种方法的一个含义是，您需要为您正在处理的每个分支提供单独的 eclipse 工作区，否则来自不同分支的项目副本会发生冲突。

【讨论】：

感谢您的回答，它似乎确实消除了我们的一些痛苦，但我更想知道 maven 约定是什么。
这样做的缺点是您永远无法确定您正在运行的任何代码的版本。如果您的 Maven 缓存过时，您可能会在不知情的情况下运行一些非常过时的代码。
@jtahlborn：是的，在这个设置中，每个人都必须在他们的 Eclipse 工作区中将所有模块作为项目打开，或者正如你所说，你永远不确定你的本地 maven repo 是否是最新的。我们没有足够的模块来解决这个问题，但其他模块可能。

【解决方案3】：

[不是真正的答案，但我有最好的答案......]

与MNG-624相关。

根据您拥有的项目数量，甚至源代码控制系统的负担也可能成为问题。

是否有人在 Maven 快照中使用独立编号方案来避免版本号混乱？理论上，您可以做没有 Maven 的事情 - 使用某种内部编号系统每周构建。构建将按照工作流程的要求部署到不同的存储库；您将需要单独的存储库用于开发、质量检查，可能需要介于两者之间的用于集成测试的存储库。当您准备发布候选版本时，请开始使用非快照版本。不过，我只是在评估 Maven - 我没有这样做的经验。

一些 Nexus 文档（针对专业版）讨论了如何进行构建登台，这可能是相关的。

【讨论】：

我必须阅读 MNG-624，感谢您的指点。我还会询问我们的 nexus 管理员是否可以访问专业文档。
Nexus 文档 - 抱歉，应该已链接。见sonatype.com/books/nexus-book/reference/index.html第9章
（还没有权限对其他人发表评论......）从下面的 JamesO 和 MattM 答案看来，关键是不要做是将版本化的 POM 检查到源代码控制中。有道理！

【解决方案4】：

过去我使用自己设计的编号方案：http://wiki.secondlife.com/wiki/Codeticket_Service

我现在处于需要再次考虑 maven 的情况，我很想重新使用 codeticket 方案来生成版本号/内部版本号并通过发布插件应用它们，但是 没有重新检查 pom 文件。签入的 pom 文件将保留 SNAPSHOT 版本号。

对于那些关心可重现构建的人，您可以在构建结果中包含修改后的 POM 文件。就个人而言，我更关心跟踪构建工件并确保最终发布完全相同的位，因此我对重现构建的担忧比大多数人都少一些 (See here)。

【讨论】：

【解决方案5】：

maven 用户列表（我参与其中）中有一个 discussion going on 似乎相关。基本上，我们正在讨论如何避免在剪切（发布或功能）分支时必须进行的所有 POM 编辑。当您创建发布分支时，发布插件可以为您进行编辑，但它对稍后需要重新集成的功能分支没有帮助。此外，当您进行合并时，所有 POM 编辑都会导致不必要的痛苦，无论是从主干进行 rebase 合并还是重新集成到主干。

这里讨论的想法是基于这样一个概念，即记录工件版本号的正确位置是在 SCM 工具中，而不是在 POM 中。基本上，maven 应该能够从与工作区域关联的实际 SCM 标签或分支中导出工件版本号。

请注意，由于 Maven 的问题跟踪器（例如MNG-2971）上仍有一些问题未解决，因此还没有完整的解决方案。但它们已经是很多投票的问题，我很乐观，它们很快就会得到解决。

【讨论】：

谢谢！这实际上是一个非常有趣的消息。我真的没有时间关注 maven 邮件列表。你知道是否有我可以订阅的官方问题/功能请求？（可能需要 MNG-2971，但它与我的理解不同）