Mavenのビルドライフサイクルについてきちんと理解するために、
Introduction to the Build Lifecycleを日本語訳してみました。
ビルドライフサイクルの基礎
Maven 2.0はビルドライフサイクルというコンセプトを基本としている。これが意味することは、特定の成果物（プロジェクト）をビルドして配布するためのプロセスが明確に定義されているということである。プロジェクトのビルド担当者は、Mavenプロジェクトをビルドするためのいくつかのコマンドの一覧を学ぶだけでよい。そうすれば、ビルド担当者が望む結果を得られるように、POMが保証してくれる。
「default」「clean」「site」という、あらかじめ規程された3つのビルドライフサイクルがあり、「default」ライフサイクルはプロジェクトの配備（デプロイ）を、「clean」ライフサイクルはプロジェクトの掃除（ビルド成果物の削除）を、また「site」ライフサイクルはプロジェクトサイト用ドキュメントの生成を扱う。
ビルドライフサイクルはいくつかの「フェーズ」から構成される
これらビルドライフサイクルは、それぞれ異なるビルドフェーズの一覧によって規定される。ビルドフェーズは、ビルドライフサイクル中の段階（ステージ）を表現している。
例えば「default」ライフサイクルは以下のビルドフェーズから構成される（ビルドフェーズの全一覧表を見たい場合は、(
Lifecycle Referenceを参照のこと」）。
- 検証（validate） - プロジェクトに誤りがないかどうか、全ての必要な情報が利用可能かどうかを検証する。
- コンパイル（compile） - プロジェクトのソースコードをコンパイルする。
- テスト（test） - 適切なユニットテスト用フレームワークを使用して、コンパイルされたソースコードをテストする。ここで言う「テスト」とは、コードがパッケージあるいはデプロイされていなくても実行可能なものを指す。
- パッケージ（package） - コンパイルされたコードを、jarなどの配布可能な形式にパッケージする
- インテグレーションテスト（integration-test） - パッケージ（された成果物）を、必要に応じてインテグレーションテストが実行可能な環境にデプロイ（配備）する。
- 確認（verify） - パッケージ（された成果物）が妥当であり、品質基準に適合することを確認するためのチェックを実行する。
- インストール（install） - ローカル環境で他プロジェクトの依存関係として利用できるように、パッケージ（された成果物）をローカルリポジトリにインストールする。
- 配備（deploy） - インテグレーションもしくはリリース環境で実行され、他の開発者やプロジェクトと共有できるように、最終パッケージをリモートリポジトリにコピーする。
これらのビルドフェーズ（に加えて、ここで示されていない他いくつかのビルドフェーズ）が順次実行されて、「default」ライフサイクルが完了する。上述のビルドフェーズについて考えると、「default」ライフサイクルが使用される場合、Mavenは
最初にプロジェクトの検証を実施し、次にソースコードのコンパイルを試み、コンパイルされたソースコードに対してテストを実行し、バイナリ（jarなど）をパッケージし、パッケージされた成果物に対してインテグレーションテストを実行し、妥当性を確認し、確認済みのパッケージをローカルリポジトリにインストールし、最後にインストール済みのパッケージを特定の環境に配備する、ということを意味する。
これらの全てを行うには、最後のビルドフェーズ、つまりこの場合は「deploy」を呼び出して実行しさえすればよい。
mvn deploy
ビルドフェーズを呼び出した場合、Mavenは該当のビルドフェーズだけでなく、それ以前に位置する全てのビルドフェーズを
実行するからである。
従って、
mvn integration-test
を実行すると、インテグレーションテストの実行前に、それ以前の全ビルドフェーズ（検証、コンパイル、パッケージ他）が実行される。
ビルドライフサイクルを構成するさらにいくつかのコマンドがあるが、それについては後のセクションで議論する。
また、同一のコマンドを複数モジュールシナリオ（a multi-module scenario、1つないしはそれ以上のサブプロジェクトを持つプロジェクトなど）でも利用できる。例えば、
mvn clean install
というコマンドは、全てのサブプロジェクトに対して、掃除（clean）とインストール（install、事前の全ステップを含む）を実行する。
ビルドフェーズは複数の「ゴール」から構成される
しかしながら、ビルドフェーズがビルドライフサイクルの特定のステップに対して責任を負うと言っても、ビルドフェーズが責務を果たす方法はそれぞれ異なる。そしてこれは、これらのビルドフェーズに結びつけられた「ゴール」を宣言することによって行われる。
ゴールは、プロジェクトのビルドと管理に寄与する、（ビルドフェーズよりも粒度の小さい）特定のタスクを表現する。ゴールは、0以上のビルドフェーズに関連付けられる。どのビルドフェーズにも関連付けられないゴールは、ビルドライフサイクル外で直接起動することによって実行できる。ゴールの実行順序は、ゴールとビルドフェーズが起動される順序次第である。例えば、以下のコマンドについて考えてみる。引数の「clean」と「package」はビルドフェーズであり、「dependency:copy-dependencies」はゴールである。
mvn clean dependency:copy-dependencies package
このコマンドが実行された場合、最初に「clean」フェーズが実行され（これは、「clean」ライフサイクルにおける、先行する全フェーズの実行を意味する）、次に「dependency:copy-dependencies」が実行される。そして最後に「package」フェーズ（および、「default」ライフサイクルでの先行する全てのビルドフェーズ）が実行される。
加えて、1つのゴールが1つ以上のビルドフェーズに結びつけられている場合、そのゴールはそれら全てのビルドフェーズ内で呼び出される。
さらに、ビルドフェーズには0ないしはそれ以上のゴールが関連付けられている。もし、ビルドフェーズが1つのゴールも持っていない場合、そのビルドフェーズは実行されない。しかし、1つ以上のゴールを持っている場合、ビルドフェーズはそれら全てのゴールを実行する（注：Maven 2.0.5以降では、1つのフェーズに結びつけられた複数のゴールはPOMに宣言されたものと同一の順序で実行されるが、同一プラグインの複数インスタンスはサポートされていない。同一プラグインの複数インスタンスはグループ化されてまとめて実行され、Maven2.0.11以降では順序付けられる？）
