什么时候应该在项目生命周期中使用mvn版本？

Question

澄清问题：

• 我正在寻找既定的最佳实践或对已知实践进行pro / con分析
• 按项目生命周期我的意思是：部署到预集成，集成，QA，preprod和prod环境。

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

我对maven发布约定不太熟悉，并且在使用mvn release时无法找到有关应用程序生命周期点的内容。

如果我们现在使用的模式被接受/正确/建立，我将有另一个问题：）

Answer 1

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

mvn release：prepare -DautoVersionSubmodules = true

P.S。我有一个图表来说明这一点，但遗憾的是，在这个论坛中没有足够的权利来附加它。如果有人可以帮助附加，我很乐意提供。

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

还要注意支持早期分支（2.1）和晚期分支（2.2）。

Answer 2

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

在构建过程中，我们有一个简单的ant build.xml，它将版本号（在maven之外建立）作为-Dversion=...参数，并且只是：

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

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

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

正如你在你的问题中所说的那样，上面说的并不是正确的方法，但是自从我们采用了maven之后，它对我们来说效果很好。我们有几十个maven模块，所有这些模块都在锁定步骤中通过QA /发布过程。

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

Answer 3

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

与MNG-624相关。

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

是否有人使用Maven快照的独立编号方案来避免版本号搅动？理论上，你可以做你没有Maven的事情 - 使用某种内部编号系统每周构建。根据工作流程的规定，构建将部署到不同的存储库;您需要单独的dev，QA存储库，可能需要一个用于集成测试的存储库。当您要发布候选版本时，请开始使用非快照版本。我只是在评估Maven，但是我没有做过这个的经验。

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

Answer 4

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

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

对于那些关心可重现构建的人，您可以在构建结果中包含修改后的POM文件。就个人而言，我更关心跟踪构建工件并确保已经测试的完全相同的位最终被释放，因此我对再现构建的关注略微不如大多数（See here）。

Answer 5

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

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

请注意，由于Maven的问题跟踪器（例如MNG-2971）仍有一些问题尚未解决，因此还没有完整的解决方案。但他们已经有许多选票的问题，而且我很乐观，他们很快就会修复。