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

Question

为了澄清这个问题：

• 我正在寻找既定的最佳实践或对已知实践的正反分析。
• 所谓项目生命周期，我指的是:部署到预集成、集成、QA、产品前和产品开发环境中.

对于某些上下文:我们的项目每周都会部署到集成和QA中，目前我们为每个集成部署创建了一个新的版本，但这感觉不太正确。这将导致每周更新所有poms，打破dev级别的依赖关系，迫使每个开发人员对eclipse配置进行刷新。我们有很大的工作空间，eclipse不能很好地处理刷新，因此浪费了大量的时间。

我不太熟悉maven发布约定，也无法找到应用程序生命周期中应该使用mvn发行版的地方。

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

Answer 1

为了避免Eclipse级依赖关系更新问题，我使用的方法是将相关的主干或分支版本号保持不变，直到发布变得重要为止。通过这种方式，您可以对QA进行适当的标记/版本发布，这样您就可以追溯问题，但不需要devs来更新依赖项。为此，我使用以下命令，但重写版本号以获得所需的发布号，但将当前快照版本重新输入为新快照版本：

mvn发行版:准备-DautoVersionSubmodules=true

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

也许现在..。

​

​

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

Answer 2

在我们的商店里，所有的SVN中的POMs都有<version>9999-SNAPSHOT</version> (对于他们自己的版本以及内部依赖)。这种情况永远不会改变。

在构建过程中，我们有一个简单的ant build.xml，它将版本号(在maven外部建立)作为-Dversion=...参数，只需：

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

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

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

正如你在你的问题中所说的，上面的问题显然不是正确的方法，但自从我们采用maven以来，它对我们的~9 mos是很有效的。我们有几十个maven模块，它们都在QA/发布过程中以锁定的方式移动。

这种方法的一个含义是，您将需要为您正在处理的每个分支分别使用eclipse工作区，因为否则来自dif分支的项目副本将发生冲突。

Answer 3

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

与MNG-624有关。

取决于您有多少项目，甚至您的源代码管理系统的负担也可能是一个问题。

是否有人使用Maven快照的独立编号方案来避免版本号的翻动?理论上说，如果没有Maven，您可以做什么--在每周的构建中使用某种类型的内部编号系统。构建将按照工作流的要求部署到不同的存储库中；对于dev、QA，您将需要单独的存储库，在两者之间可能需要一个存储库进行集成测试。当您开始发布候选版本时，请开始使用非快照版本。不过，我只是在评估Maven -我没有这样做的经验。

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