質問を明確にするために：
コンテキストによっては：私たちのプロジェクトは毎週統合とQAにデプロイされ、現在、統合デプロイメントごとに新しいリリースを作成していますが、これは正しくないと感じています。これにより、毎週すべてのpomが更新され、開発者レベルの依存関係が解消され、すべての開発者がEclipse構成を更新する必要があります。私たちは大きなワークスペースを持っており、Eclipseは更新をあまりうまく処理しないため、多くの無駄な時間があります。
私はMavenリリースの規則にあまり精通しておらず、mvnリリースを使用する必要があるアプリケーションライフサイクルのポイントに関する規則を見つけることができませんでした。
現在使用しているパターンが受け入れられた/正しい/確立された場合、別の質問があります:)
Eclipse開発レベルの依存関係の更新の問題を回避するために私が使用するアプローチは、リリースが重要になるまで、関連するトランクまたはブランチのバージョン番号を変更しないままにすることです。このようにして、QAなどに適切にタグ付け/バージョン管理されたリリースを作成できるため、問題を追跡できますが、開発者が依存関係を更新する必要はありません。これを実現するには、次のコマンドを使用しますが、バージョン番号を上書きして目的のリリース番号を取得しますが、現在のスナップショットバージョンを新しいスナップショットバージョンとして再入力します。
mvn release：prepare -DautoVersionSubmodules = true
PS私はこれを示す図を持っていますが、残念ながらこのフォーラムにはそれを添付するための不十分な権利があります。誰かが取り付けを容易にすることができれば、私は喜んでそれを提供します。
PPSたぶん今...
アーリーブランチ（2.1）とレイトブランチ（2.2）のサポートにも注意してください。
当店では、SVNのすべてのPOMに<version>9999-SNAPSHOT</version>（独自のバージョンと内部依存関係のために）あります。これは決して変わりません。
build.xmlビルド中に、バージョン番号（Mavenの外部で確立された）を-Dversion=...パラメーターとして受け取る単純なantがあり、単純に次のことを行います。
<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/>
<artifact:mvn ... />
この変更は、ビルドプロセスの作業コピーに対してローカルであり、バージョン管理にチェックインされることはありません。
このように、すべてのリリースビルドには「実際の」バージョン番号がありますが、devは事実上バージョン番号を処理する必要はありません。
上記は、あなたの質問で言うように、これを行う正しい方法ではないことを強調していますが、Mavenを採用してから約9か月間はうまく機能しました。数十のMavenモジュールがあり、それらはすべてQA/リリースプロセスをロックステップで実行します。
このアプローチの1つの意味は、作業しているブランチごとに個別のEclipseワークスペースが必要になることです。そうしないと、異なるブランチからのプロジェクトのコピーが衝突します。
[実際には答えではありませんが、私が持っている最高のものです...]
MNG-624に関連します。
プロジェクトの数によっては、ソース管理システムの負担さえ問題になる場合があります。
バージョン番号の混乱を避けるために、Mavenスナップショットで独立した番号付けスキームを使用している人はいますか？ 理論的には、Mavenがなくても実行できることを実行できます。毎週のビルドには、ある種の内部番号付けシステムを使用します。ビルドは、ワークフローの指示に従って、さまざまなリポジトリにデプロイされます。開発用、QA用に別々のリポジトリが必要になります。統合テスト用にその中間にある可能性があります。候補版をリリースするときは、スナップショット以外のリリースの使用を開始します。私はMavenを評価しているだけですが、これを行った経験はありません。
一部のNexusドキュメント（Professionalバージョン用）では、ビルドステージングの実行方法について説明しています。これは関連性がある場合があります。
過去には、私は自分で考案した番号付けスキームを使用していました：http ://wiki.secondlife.com/wiki/Codeticket_Service
私は今、Mavenについてもう一度考える必要がある状況にあり、コードチケットスキームを再利用してバージョン番号/ビルド番号を生成し、リリースプラグインを介してそれらを適用したいと思っていますが、pomファイルをチェックインし直さないでください。チェックインされたpomファイルは、SNAPSHOTのバージョン番号を保持します。
再現性のあるビルドを気にする人のために、変更したPOMファイルをビルド結果に含めることができます。個人的には、ビルドアーティファクトを追跡し、テストされたものとまったく同じビットがリリースされるようにすることに関心があります。そのため、ビルドの再現に関する私の懸念は、ほとんどの場合よりも少し宗教的ではありません（ここを参照）。
（私が参加している）Mavenユーザーリストで、関連性があると思われる議論が行われています。基本的に、（リリースまたは機能）ブランチをカットするたびに実行する必要のあるPOM編集をすべて回避する方法について説明しています。リリースプラグインは、リリースブランチを作成するときに編集を行うことができますが、後で再統合する必要がある機能ブランチには役立ちません。また、POMの編集はすべて、トランクからのリベースマージまたはトランクへの再統合マージのいずれかで、マージを行うときに不必要な苦痛を引き起こします。
そこで議論されている考え方は、アーティファクトのバージョン番号を記録する適切な場所はPOMではなくSCMツールにあるという概念に基づいています。基本的に、Mavenは、作業領域が関連付けられている実際のSCMタグまたはブランチからアーティファクトのバージョン番号を取得できる必要があります。
Mavenの課題追跡システム（ MNG-2971など）でまだ保留中の問題があるため、完全な解決策はまだないことに注意してください。しかし、それらはすでに多くの票を獲得している問題であり、私はそれらがすぐに修正されることを楽観視しています。