Maven は、ライフサイクルの順序に従ってプラグインのゴールを実行することでプロジェクトをビルドします。ライフサイクルには順序付けられたフェーズが含まれます。あるフェーズを呼び出すと、同じライフサイクル内のそのフェーズと、それより前のすべてのフェーズが実行されます。プラグインはゴールを提供し、ライフサイクルバインディングは、プロジェクトのパッケージングに応じて実行するゴールを選択します。
プロジェクトモデルと座標 #
POM は、groupId、artifactId、version、packaging によってアーティファクトを識別します。親 POM、依存関係管理、インポートした BOM によって、アーティファクトをクラスパスに追加せずにバージョンを一元管理できます。したがって dependencyManagement は、子 POM が依存関係を宣言した後でのみ、その依存関係を制約します。
継承と集約は独立しています。子プロジェクトは <parent> で指定された POM を継承します。一方、アグリゲーターは <modules> にリアクタープロジェクトを列挙し、依存関係の順序に従ってビルドします。1 つの POM が両方の役割を担うことはできますが、モジュールがアグリゲーターから継承する必要はありません。マージ後のモデルと有効なプロファイルを確認するには、次を実行します。
mvn help:effective-pom
mvn help:active-profilesリポジトリ、認証情報、デプロイ設定は分離して管理します。
- プロジェクトで必要な場合に限り、プロジェクトリポジトリをコミットします。
- 認証情報と組織固有のミラーは POM ではなく、ユーザーまたは CI の
settings.xmlに配置します。 - 依存関係とプラグインのバージョンは、直接宣言するか、レビュー済みの管理セクションを通じて明示します。プラグインのバージョンを省略すると、ビルドはソースツリーではなく Maven の解決動作に依存します。
ライフサイクルとフェーズ #
Maven は clean、default、site のライフサイクルを提供します。日常的なビルドでは default ライフサイクルを使用します。
| フェーズ範囲 | 目的 |
|---|---|
validate から process-resources まで | モデルを検証し、入力を生成し、リソースを準備します。 |
compile から test まで | 本番コードとテストコードをコンパイルし、ユニットテストを実行します。 |
package | JAR、WAR、その他の配布可能なアーティファクトを作成します。 |
pre-integration-test から post-integration-test まで | 統合テスト環境を準備、実行、解体します。 |
verify | テスト後に品質チェックを実行します。 |
install | アーティファクトをローカルリポジトリに追加します。 |
deploy | アーティファクトをリモートリポジトリに公開します。 |
mvn verify は、アーティファクトを公開せずに検証フェーズまで到達するため、CI の基準コマンドとして適しています。mvn clean verify は、以前のビルド出力も削除します。clean ライフサイクルには pre-clean、clean、post-clean があり、clean は生成されたビルドファイルを削除します。site ライフサイクルは、プロジェクトのドキュメントを生成し、公開することもできます。
プラグイン、ゴール、実行定義 #
プラグインはビルド時に実行されるコードであり、プロジェクトの依存関係ではありません。有効なビルドプラグインは build/plugins に設定します。build/pluginManagement には、子 POM または同じ POM が明示的に有効化する必要のあるバージョンと共有設定を定義します。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
<configuration>
<release>21</release>
</configuration>
</plugin>
</plugins>
</build>実行定義は、1 つ以上のゴールをフェーズにバインドします。パッケージング固有のデフォルトバインディングは、Java ソースのコンパイルや JAR の作成など、一般的なゴールを提供します。実行定義で <phase> を省略した場合は Mojo の defaultPhase が使用されますが、それだけで任意のサードパーティー製ゴールがバインドされることはありません。
<plugin>
<groupId>org.example</groupId>
<artifactId>example-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals><goal>generate</goal></goals>
</execution>
</executions>
</plugin>プレフィックスまたは完全な座標を指定して、ゴールを直接呼び出せます。
mvn dependency:tree
mvn org.apache.maven.plugins:maven-dependency-plugin:3.7.1:treeプレフィックスの解決では、設定済みのプラグイングループとリポジトリが検索されることがあります。POM がプラグインをすでに宣言していない場合、自動化では完全な座標を指定する方が適しています。
プラグインの内部構造とプレフィックス解決 #
プラグインアーティファクトは <packaging>maven-plugin</packaging> によって識別されます。実行単位は Mojo であり、AbstractMojo のサブクラスとして実装されます。プラグイン自身の POM では、maven-plugin-plugin を通じて <goalPrefix> を定義できます。このプレフィックスが短い CLI 名になります。
プレフィックスの解決は、次の層で行われます。
- プロジェクトが要求されたプレフィックスのプラグインをすでに宣言している場合、Maven は有効な POM から解決できます。
- それ以外の場合、Maven は組み込みの
org.apache.maven.pluginsグループと、settings.xmlに宣言された追加のpluginGroupsを確認します。 - 必要に応じて、
maven-XXX-pluginやXXX-maven-pluginなどの artifactId 規約にフォールバックします。
この解決モデルにより、完全修飾座標がなくても mvn dependency:tree を実行できます。一方、自動化では明示的な groupId:artifactId:version:goal 形式が好まれます。
@Mojo の defaultPhase 属性は、明示的な実行定義に対してのみフェーズを提供します。非公式プラグインに対する自動バインディングは作成しません。ライフサイクルバインディングは、アノテーションだけでなく、パッケージングモデルと Maven の組み込みデフォルトバインディングから提供されます。
依存関係とスコープ #
Maven は、スコープに従って直接依存関係と推移的依存関係を解決し、クラスパスを構成します。
| スコープ | メインコンパイル | メイン実行時 | テストのコンパイルと実行時 |
|---|---|---|---|
compile | yes | yes | yes |
provided | yes | no | yes |
runtime | no | yes | yes |
test | no | no | yes |
provided は、Servlet コンテナなど、デプロイ環境が互換性のある API を提供する場合に限って使用します。runtime は、コンパイラが必要としないドライバーや実装に適しています。system はローカルファイルパスを要求し、通常のリポジトリ解決を回避するため、再現可能なビルドには使用しないでください。import は POM 依存関係にのみ適用され、BOM を依存関係管理にインポートします。
バージョンの仲介と除外を確認するには、mvn dependency:tree を使用します。Maven の最近接定義ルールは、競合する推移的バージョンの中から 1 つを選択します。同じ深さの場合は、宣言順で解決されます。直接宣言または dependencyManagement エントリによって、選択を明示できます。除外は、それを宣言した依存関係パスにのみ適用されるため、個別に散在する除外よりも管理セクションまたは BOM を優先します。
リポジトリ、ミラー、設定 #
リポジトリはアーティファクトの提供元です。ミラーは、選択したリポジトリへのリクエストをリダイレクトする settings.xml のルールです。依存関係を追加したり、リポジトリの認証ポリシーを置き換えたりするものではありません。
<mirrors>
<mirror>
<id>company-proxy</id>
<mirrorOf>central</mirrorOf>
<url>https://repository.example.invalid/maven-central</url>
</mirror>
</mirrors>グローバル設定ファイルは Maven のインストール先にあり、ユーザー設定ファイルは ~/.m2/settings.xml にあります。CI では、シークレット管理の仕組みを通じて最小限の設定ファイルを提供します。リポジトリのパスワードを POM に保存しないでください。Maven の <relocation> メタデータを使用すると、公開者は古い座標を置換先の座標へリダイレクトできます。
Maven Wrapper #
mvnw、mvnw.cmd、.mvn/wrapper/ をコミットし、開発者と CI が宣言された Maven ディストリビューションを使用するようにします。
mvn wrapper:wrapper -Dmaven=3.9.9
./mvnw clean verifyWrapper を更新する際は、ディストリビューション URL とチェックサムを確認します。Wrapper が固定するのは Maven 自体であり、プラグインと依存関係のバージョンには引き続き POM による管理が必要です。
コメント
GitHub で閲覧・コメントする(投稿にはログインが必要です)