项目生命周期什么时候应该使用mvnrelease？
为了澄清这个问题：
- 我正在寻找已建立的最佳实践或
- 按项目生命周期对已知实践进行赞成/反对分析，我的意思是：部署到预集成、集成、QA、预生产和生产环境。
对于某些上下文： 我们的项目每周都会部署到集成和 QA，目前我们为每个集成部署创建一个新版本，但这感觉不对。它导致每周更新所有 poms，从而打破开发级别依赖关系，迫使每个开发人员刷新其 eclipse 配置。我们有很大的工作空间，而 Eclipse 不能很好地处理刷新，因此浪费了很多时间。
我不太熟悉 Maven 发布约定，并且无法找到有关应使用 mvn 发布的应用程序生命周期点的约定。
如果我们现在使用的模式被接受/正确/建立，我会有另一个问题:)
To clarify the question :
- I am looking for established best-practices or a pro/con analysis of known practices
- by project lifecycle I mean : deploy to pre-integration, integration, QA, preprod and prod environment.
For some context:
Our project deploys to integration and QA every week, currenlty we create a new release for each integration deployment, but this doesn't feel right. It leads to updating all the poms every week breaking dev level dependencies, forcing every dev to do a refresh of their eclipse configurations. We have large workspaces and eclipse doesn't handle the refreshes so well thus a lot of wasted time.
I am not overly familiar with the maven release conventions and have been unable to find the ones regarding the point of the application lifecycle when mvn release should be used.
If the pattern we use now is accepted/correct/established I will have another question :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在我们的商店中，SVN 中的所有 POM 都有
9999-SNAPSHOT 在构建过程中，我们有一个简单的 ant
build.xml，它将版本号（在 maven 外部建立）作为-Dversion=...参数，并且简单地执行:<替换includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/>该更改是构建过程的工作副本的本地更改 - 它永远不会签入版本控制。
这样，所有发布版本都有一个“真实”版本号，但开发人员实际上永远不必处理版本号。
正如您在问题中所说，上述内容显然不是执行此操作的正确方法，但自从我们采用 maven 以来，它在大约 9 个月内对我们来说效果很好。我们有数十个 Maven 模块，所有这些模块都在 QA/发布过程中同步进行。
这种方法的一个含义是，您需要为正在处理的每个分支提供单独的 Eclipse 工作区，否则来自不同分支的项目副本将会发生冲突。
In our shop, all of our POMs in SVN have
<version>9999-SNAPSHOT</version>(for their own version as well as internal dependencies). This never changes.During the build, we have a simple ant
build.xmlthat takes the version number (established outside of maven) as a-Dversion=...parameter, and simply does:<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/><artifact:mvn ... />That change is local to the build process's working copy -- it's never checked in to version control.
This way all release builds have a "real" version number, but dev effectively never has to deal with version numbers.
The above is, as you say in your question, emphatically not The Right Way to do this, but it has worked well for us for the ~9 mos since we adopted maven. We have tens of maven modules, all of which move in lock-step through the QA/release process.
One implication of this approach is that you'll need separate eclipse workspaces for each branch you're working on, as otherwise the copies of a project from dif't branches will collide.
[不是真正的答案，但我拥有的最好的答案...]
与 MNG-624。
根据您拥有的项目数量，甚至源代码控制系统的负担也可能是一个问题。
有人对 Maven 快照使用独立的编号方案来避免版本号搅动吗？理论上，您可以做没有 Maven 时所做的事情 - 对每周构建使用某种内部编号系统。构建将根据工作流程部署到不同的存储库；您将需要单独的存储库用于开发、QA，也许其中一个用于集成测试。当您准备发布候选版本时，请开始使用非快照版本。不过，我只是在评估 Maven - 我没有这方面的经验。
一些 Nexus 文档（针对专业版）讨论了如何进行构建暂存，这可能是相关的。
[Not really an answer, but the best I have...]
Related to MNG-624.
Depending on how many projects you have, even the burden on your source-control system may be an issue.
Does anyone use an independent numbering scheme with Maven snapshots to avoid version-number churning? In theory, you could do what you'd do without Maven - use an internal numbering system of some kind for the weekly builds. The builds would be deployed to different repositories as dictated by workflow; you'll need separate repositories for dev, QA, maybe one in between for integration test. When you're down to release candidates, start using non-snapshot releases. I'm just evaluating Maven, though - I've no experience with doing this.
Some of the Nexus documentation (for the Professional version) talks about how to do build staging, which may be relevant.
过去，我使用了自己设计的编号方案： http://wiki.secondlife.com/wiki/ Codeticket_Service
我现在的情况是需要再次考虑maven，我很想重新使用codeticket方案来生成版本号/内部版本号并通过发布插件应用它们，但是没有检查回pom文件。签入的 pom 文件将保留 SNAPSHOT 版本号。
对于那些关心可重现构建的人，您可以将修改后的 POM 文件包含在构建结果中。就我个人而言，我更关心跟踪构建工件并确保已测试的完全相同的位最终得到发布，因此我对复制构建的关注比大多数人稍微不那么虔诚（参见此处）。
In the past I used a numbering scheme of my own devising: http://wiki.secondlife.com/wiki/Codeticket_Service
I'm now in the situation where I need to think about maven again, and I'm tempted to re-use the codeticket scheme to generate version numbers/build numbers and apply them via the release plugin but without checking the pom files back in. The checked in pom files will keep the SNAPSHOT version numbers.
For those who care about reproducible builds, you can include the modified POM file in your build result. Personally, I care more about tracking the build artifacts and ensuring that the exact same bits that have been tested end up getting released, so my concern about reproducing builds is slightly less religious than with most (See here).
有一个 maven 用户列表（我正在参与其中）中正在进行的讨论似乎相关。基本上，我们正在讨论如何避免每次剪切（发布或功能）分支时必须进行的所有 POM 编辑。当您创建发布分支时，发布插件可以为您进行编辑，但对于稍后需要重新集成的功能分支没有帮助。此外，当您进行合并时，所有 POM 编辑都会带来不必要的痛苦，无论是从主干进行变基合并，还是重新集成合并到主干。
那里讨论的想法基于以下概念：记录工件版本号的正确位置是在 SCM 工具中，而不是在 POM 中。基本上，maven 应该能够从工作区域关联的实际 SCM 标记或分支导出工件版本号。
请注意，由于 Maven 的问题跟踪器上仍有一些问题悬而未决，因此还没有完整的解决方案（例如 MNG-第2971章但这些问题已经得到了很多选票，我乐观地认为它们很快就会得到解决。
There is a discussion going on in the maven users list (in which I'm participating) that seems relevant. Basically we're discussing how to avoid all that POM editing that has to be done whenever you cut a (release or feature) branch. The release plugin can do the editing for you, when you create a release branch, but it does not help with feature branches that need to be reintegrated later. Also, all that POM editing causes unecessary pain when you do merges, either rebase merges from trunk or reintegration merges to trunk.
The idea being discussed there is based on the notion that the proper location to record artifact version numbers is in the SCM tool and not in the POM. Basically, maven should be able to derive the artifact version number from the actual SCM tag or branch that the working area is associated to.
Note that there is not a complete solution yet due to some issues still pending on Maven's issue tracker (e.g. MNG-2971). But they are issues with many votes already and I'm optimist they will be fixed soon.
我用来避免 Eclipse 开发级别依赖项更新问题的方法是保持相关主干或分支版本号不变，直到版本变得重要为止。通过这种方式，您可以对 QA 等进行正确标记/版本控制的版本，以便您可以跟踪问题，但不需要开发人员更新依赖项。为了实现此目的，我使用以下命令，但覆盖版本号以获取所需的版本号，但重新输入当前快照版本作为新的快照版本：
release:prepare -DautoVersionSubmodules=true
mvn 我有一个图表可以说明这一点，但不幸的是，该论坛没有足够的权限来附加它。如果有人可以帮助附加，我很乐意提供它。
PPS 也许现在...
另请注意对早期分支 (2.1) 和晚期分支 (2.2) 的支持。
The approach I use to avoid the Eclipse dev level dependency update issue is to leave the relevant trunk or branch version number unchanged until such time as the release becomes significant. This way you can have properly tagged/versioned releases to QA etc so that you can track issues back but not require devs to update dependencies. To achieve this I use the following command but override the version numbers to get the desired release number but re-enter the current snapshot version as the new snapshot version:
mvn release:prepare -DautoVersionSubmodules=true
P.S. I have a diagram that demonstrates this but unfortunately insufficient rights in this forum to attach it. I would happily provide it if someone can facilitate attaching.
P.P.S Maybe now...
Note also the support for early branching (2.1) and late branching (2.2).