【入門】Maven の使い方・基本をわかりやすく解説

By /

はい、承知いたしました。Mavenの入門者向け解説記事を約5000語で執筆します。記事の内容をそのまま表示します。

【入門】Mavenの使い方・基本をわかりやすく解説

Java開発において、プロジェクト管理やビルド自動化は非常に重要な要素です。かつては手作業でライブラリ（JARファイル）を集めたり、複雑なコンパイルコマンドを記述したりすることも珍しくありませんでしたが、現代のJava開発では、Mavenのようなビルド自動化ツールが不可欠となっています。

この記事は、「Mavenを初めて使う」「Mavenについて名前は聞いたことがあるけれど、どういうものか分からない」「Java開発を始めたばかりで、モダンなビルドツールを知りたい」といった入門者の方々を対象に、Mavenの基本的な使い方から主要な概念までを、できるだけ分かりやすく、詳細に解説することを目的としています。

この記事を読むことで、Mavenの役割、プロジェクトの作成方法、依存関係の管理、ビルドの実行方法など、Java開発プロジェクトでMavenを使い始めるために必要な知識を体系的に理解できるでしょう。さあ、Mavenの世界へ一歩踏み出しましょう。

1. Mavenとは何か？ なぜ使うのか？

1.1 Java開発における課題

Mavenが登場する以前、あるいはMavenのようなツールを使わない場合、Javaプロジェクトの開発にはいくつかの共通した課題がありました。

  1. 依存関係の管理: 自分のプロジェクトが他のライブラリ（例: ログ出力のためのLog4j、データベース接続のためのJDBCドライバ、Webフレームワークなど）に依存する場合、それらのライブラリのJARファイルを自分でダウンロードし、プロジェクトのクラスパスに追加する必要がありました。さらに、それらのライブラリが別のライブラリに依存している（推移的依存関係）場合、芋づる式に必要なJARファイルを全て手動で集めなければなりませんでした。ライブラリのバージョン管理も煩雑で、特定のバージョンが必要なのに別のバージョンが混在したり、互換性のないバージョンの組み合わせで問題が発生したりすることもよくありました。
  2. ビルドプロセスの標準化: プロジェクトを「ビルド」する（ソースコードをコンパイルし、テストを実行し、実行可能な形式にまとめる）プロセスは、プロジェクトごとに異なるスクリプトや手順に依存することが多かったです。これにより、新しい開発者がプロジェクトに参加した際にビルド方法を理解するのに時間がかかったり、開発環境によってビルド結果が異なったりする問題が生じました。
  3. プロジェクト構造の統一性: プロジェクトのソースコード、リソースファイル、テストコード、生成物などをどこに配置するかについての標準がなく、プロジェクトごとにディレクトリ構造がバラバラでした。これもまた、プロジェクトの可読性や保守性を低下させる要因となりました。

1.2 Mavenの登場と役割

これらの課題を解決するために登場したのが、Mavenのようなビルド自動化ツールです。Mavenは、Apacheソフトウェア財団によって開発された、Javaプロジェクトのビルド自動化ツールであり、プロジェクト管理ツールでもあります。

Mavenの主な役割は以下の通りです。

  1. 依存関係の自動管理: プロジェクトがどのライブラリのどのバージョンに依存しているかを記述しておけば、Mavenが自動的にインターネット上のリポジトリから必要なライブラリをダウンロードし、プロジェクトのクラスパスに追加してくれます。推移的な依存関係も自動的に解決してくれるため、開発者は必要なライブラリの直接的な依存関係のみを記述すれば済みます。
  2. 標準化されたプロジェクト構造: Mavenは、推奨される標準的なディレクトリ構造（Standard Directory Layout）を持っています。これにより、どのMavenプロジェクトでもソースコードは src/main/java、テストコードは src/test/java にある、といった共通の認識を持つことができ、プロジェクトの構造を素早く理解できます。
  3. 標準化されたビルドプロセス: Mavenは「ビルドライフサイクル」という概念を持っており、プロジェクトのビルドプロセスを compile (コンパイル)、test (テスト実行)、package (パッケージング) といった一連の「フェーズ」として定義しています。開発者は mvn package といった標準コマンドを実行するだけで、プロジェクトの種類に応じた適切なビルドプロセスを実行できます。これにより、ビルドプロセスが標準化され、誰でも同じ手順でビルドできるようになります。
  4. プロジェクト情報の一元管理: プロジェクト名、バージョン、開発者情報、ライセンス、依存関係、ビルド設定といったプロジェクトに関するあらゆる情報を、pom.xml という一つのファイルに集約して管理します。pom.xml は「Project Object Model」の略で、プロジェクトの設計図のようなものです。
  5. プラグインによる機能拡張: コンパイル、テスト実行、レポート生成、WAR/JARファイルの作成、ドキュメント生成など、ビルドプロセスにおける具体的な処理は、Mavenの「プラグイン」によって実現されます。Mavenは多くの標準プラグインを提供しており、必要に応じてカスタマイズしたり、サードパーティ製のプラグインを追加したりすることで、機能を拡張できます。

1.3 Mavenを使うメリット

Mavenを導入することで、開発者は以下のメリットを得られます。

  • 開発効率の向上: 依存ライブラリの管理やビルドの手間が大幅に削減されます。
  • プロジェクトの保守性向上: 標準化された構造とビルドプロセスにより、プロジェクトの理解やメンテナンスが容易になります。
  • チーム開発の円滑化: 開発環境によらず再現性の高いビルドが可能になり、チームメンバー間の作業がスムーズになります。
  • 新しいメンバーのオンボーディング: プロジェクトの構造やビルド方法が標準化されているため、新しいメンバーがプロジェクトに慣れるのが早くなります。
  • 推移的依存関係の自動解決: 必要なライブラリの依存ライブラリを自動的に見つけてくれるため、バージョン衝突などの問題を避けやすくなります。

Java開発を行う上で、Mavenはもはやデファクトスタンダードと言える存在です。その基本的な使い方を習得することは、現代のJava開発者にとって必須スキルとなっています。

2. Mavenのインストールとセットアップ

Mavenを使い始めるには、まずお使いのシステムにMavenをインストールする必要があります。

2.1 前提条件

Mavenを実行するには、Java Development Kit (JDK) がインストールされている必要があります。JDK 1.7以上が推奨されていますが、最新のMavenバージョンを使用する場合は、より新しいJDKバージョン（JDK 8以上、できればJDK 11以降）が必要です。まだJDKをインストールしていない場合は、Oracle JDKやOpenJDKなど、いずれかのJDKを事前にインストールしてください。また、環境変数 JAVA_HOME がJDKのインストールディレクトリを指すように設定されていることを確認してください。

2.2 Mavenのダウンロード

Mavenの公式ウェブサイトから最新版をダウンロードします。

  1. Apache Mavenのダウンロードページ (https://maven.apache.org/download.cgi) にアクセスします。
  2. “Files” セクションにある、バイナリディストリビューションのアーカイブファイル (例: apache-maven-x.x.x-bin.zip または apache-maven-x.x.x-bin.tar.gz) をダウンロードします。x.x.x はバージョン番号です。

2.3 Mavenのインストール手順

ダウンロードしたファイルを解凍し、任意の場所に配置します。ここでは、例としていくつかのOSにおける一般的な配置場所と環境変数設定を説明します。

Windows:

  1. ダウンロードした apache-maven-x.x.x-bin.zip を、例えば C:\Program Files\Apache\maven のようなディレクトリに解凍します。解凍すると、apache-maven-x.x.x という名前のフォルダが作成されます。
  2. 環境変数を設定します。
    • システムのプロパティを開き、「環境変数」をクリックします。
    • 「システム環境変数」のリストで「新規」をクリックします。
    • 変数名に M2_HOME、変数値にMavenを解凍したディレクトリ (例: C:\Program Files\Apache\maven\apache-maven-x.x.x) を入力し、「OK」をクリックします。
    • 「システム環境変数」のリストで Path 変数を選択し、「編集」をクリックします。
    • 新規エントリとして %M2_HOME%\bin を追加します。（Windows 10以降の場合）あるいは、既存の値の末尾に ;%M2_HOME%\bin を追加します。（古いWindowsの場合）
    • 全てのダイアログで「OK」をクリックして閉じます。

macOS / Linux:

  1. ダウンロードした apache-maven-x.x.x-bin.tar.gz を、任意のディレクトリに解凍します。例えば、/opt/apache-maven や $HOME/apache-maven などです。コマンドラインで解凍する場合：
    bash
    tar zxvf apache-maven-x.x.x-bin.tar.gz
    sudo mv apache-maven-x.x.x /opt/apache-maven
  2. 環境変数を設定します。設定ファイルはシェルによって異なります（例: ~/.bash_profile, ~/.zshrc, ~/.profile）。お使いのシェルの設定ファイルに以下の行を追加します。
    bash
    export M2_HOME=/opt/apache-maven/apache-maven-x.x.x # Mavenを解凍したディレクトリのパスに置き換えてください
    export PATH=$PATH:$M2_HOME/bin
  3. 設定ファイルを再読み込みするか、ターミナルを再起動して変更を適用します。
    bash
    source ~/.bash_profile # またはお使いの設定ファイル

2.4 インストールの確認

コマンドプロンプトまたはターミナルを開き、以下のコマンドを実行してMavenが正しくインストールされ、環境変数が設定されているか確認します。

bash
mvn -v

以下のようなMavenのバージョン情報が表示されれば成功です。

Apache Maven x.x.x (...)
Maven home: /opt/apache-maven/apache-maven-x.x.x
Java version: x.x.x, vendor: ..., runtime: ...
Default locale: ..., platform encoding: ...
OS name: "...", version: "...", arch: "...", family: "..."

もし command not found: mvn のようなエラーが出る場合は、環境変数の設定が間違っている可能性があります。M2_HOME がMavenディレクトリのルートを指しているか、Path に %M2_HOME%\bin (Windows) または $M2_HOME/bin (macOS/Linux) が含まれているかを再確認してください。設定変更後にターミナルを再起動するのを忘れないようにしましょう。

これでMavenを使用する準備が整いました。

3. Mavenプロジェクトの作成

Mavenを使い始める最も簡単な方法は、MavenのArchetype (アーキタイプ) 機能を使ってプロジェクトのひな形を作成することです。Archetypeは、特定の種類のプロジェクト（簡単なJavaアプリケーション、Webアプリケーションなど）の標準的なディレクトリ構造や基本的なpom.xmlファイルを生成するためのテンプレートです。

3.1 標準ディレクトリ構造 (Standard Directory Layout)

Mavenプロジェクトは、共通のディレクトリ構造を採用しています。これは、どのMavenプロジェクトも同じように扱えるようにするための重要な要素です。主要なディレクトリは以下の通りです。

  • プロジェクトルート/
    • pom.xml (プロジェクト設定ファイル)
    • src/
      • main/ (本番コード関連)
        • java/ (Javaソースコード)
        • resources/ (リソースファイル – プロパティファイル、XML設定ファイルなど)
        • webapp/ (Webアプリケーションの場合 – JSP, HTML, CSSなど)
      • test/ (テストコード関連)
        • java/ (Javaテストソースコード)
        • resources/ (テスト用リソースファイル)
    • target/ (ビルド生成物 – コンパイル済みクラス、JAR/WARファイル、テストレポートなど。ビルド時に自動生成され、クリーンアップされる可能性のあるディレクトリ)

開発者は主に src/main と src/test ディレクトリで作業を行います。target ディレクトリはMavenによって管理されます。

3.2 Archetypeを使ったプロジェクト作成

コマンドラインを使って、簡単なJavaアプリケーションプロジェクトを作成してみましょう。

  1. プロジェクトを作成したいディレクトリに移動します。
    bash
    cd /path/to/your/projects
  2. 以下の mvn archetype:generate コマンドを実行します。これは、archetypeプラグインのgenerateゴールを実行するという意味です。
    bash
    mvn archetype:generate
  3. コマンドを実行すると、対話形式でいくつかの情報を求められます。
    • Choose archetype: 利用可能なArchetypeのリストが表示されます。入門用としては maven-archetype-quickstart が最も適しています。リストの中から maven-archetype-quickstart に対応する番号を入力するか、フィルタリング機能を使って検索できます。あるいは、コマンド実行時に -DarchetypeArtifactId=maven-archetype-quickstart オプションを指定することもできます。
    • Define value for property ‘groupId’: プロジェクトのグループIDを入力します。通常、組織や個人のドメイン名を逆順にしたものを使用します。（例: com.example, jp.co.yourcompany）
    • Define value for property ‘artifactId’: プロジェクトのアーティファクトIDを入力します。これはプロジェクトの名前です。（例: my-first-maven-app, simple-java-project）
    • Define value for property ‘version’: プロジェクトのバージョンを入力します。デフォルトは 1.0-SNAPSHOT です。学習段階ではこのままで構いません。-SNAPSHOT は「開発中のバージョン」であることを示します。
    • Define value for property ‘package’: 生成されるJavaコードのパッケージ名を入力します。デフォルトは groupId と同じです。そのままEnterを押すか、必要に応じて変更します。
    • Confirm properties: 入力した情報が表示されるので、間違いがなければ Y を入力して確定します。

以下は、maven-archetype-quickstart を指定して対話形式をスキップし、コマンドラインオプションで必要な情報を全て指定する例です。

bash
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DarchetypeArtifactId=maven-archetype-quickstart \
-DarchetypeVersion=1.4 \
-DgroupId=com.example \
-DartifactId=my-first-maven-app \
-Dversion=1.0-SNAPSHOT \
-Dpackage=com.example.app \
-DinteractiveMode=false
（バックスラッシュ \ はコマンドを複数行に分割するためのもので、必須ではありません。一行で書いても構いません。）

このコマンドを実行すると、指定した artifactId (例: my-first-maven-app) と同じ名前のディレクトリが作成され、その中にMavenの標準ディレクトリ構造と、基本的なpom.xmlファイル、そして簡単なサンプルJavaクラスとテストクラスが生成されます。

生成されたプロジェクト構造は以下のようになります。

my-first-maven-app/
├── pom.xml
└── src/
├── main/
│ ├── java/
│ │ └── com/
│ │ └── example/
│ │ └── app/
│ │ └── App.java
│ └── resources/
└── test/
├── java/
│ └── com/
│ └── example/
│ └── app/
│ └── AppTest.java
└── resources/

これで、Mavenプロジェクトのひな形が作成されました。次に、このプロジェクトの最も重要なファイルである pom.xml の内容を見ていきましょう。

4. pom.xml の詳細

pom.xml は、Mavenプロジェクトの「Project Object Model」であり、プロジェクトの設定や依存関係、ビルド方法など、あらゆる情報が記述された中心的なファイルです。XML形式で記述されます。

Archetypeで生成された my-first-maven-app プロジェクトの pom.xml を見てみましょう。内容はArchetypeのバージョンによって多少異なりますが、基本的な構成は同じです。

“`xml
4.0.0

<groupId>com.example</groupId>
<artifactId>my-first-maven-app</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>my-first-maven-app</name>
<url>http://www.example.com</url>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.7</maven.compiler.source>
    <maven.compiler.target>1.7</maven.compiler.target>
</properties>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.11</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.0</version>
            <configuration>
                <source>${maven.compiler.source}</source>
                <target>${maven.compiler.target}</target>
            </configuration>
        </plugin>
    </plugins>
</build>

“`

各要素の意味を詳しく見ていきます。

4.1 ルート要素 <project>

pom.xml の最上位の要素は <project> です。この要素内に全てのプロジェクト設定を記述します。xmlns属性はXML名前空間の定義で、MavenがXMLファイルを正しく解釈するために必要です。通常はこの定義をそのまま使用します。

4.2 <modelVersion>

使用しているPOMのモデルバージョンを指定します。現在のMavenでは 4.0.0 が標準です。

4.3 プロジェクトの基本情報 (GAV座標)

全てのMavenプロジェクトは、以下の3つの要素で一意に識別されます。これをGAV座標と呼びます。

  • <groupId>: プロジェクトが所属するグループや組織を識別します。通常、組織のドメイン名を逆順にしたものを使用します（例: com.example）。個人のプロジェクトであれば、GitHubのユーザー名などを使用しても良いでしょう。
  • <artifactId>: プロジェクト自身を識別する名前です。プロジェクト名を表すことが多いです（例: my-first-maven-app）。
  • <version>: プロジェクトの現在のバージョンを指定します（例: 1.0-SNAPSHOT）。バージョン番号は、開発中の場合は -SNAPSHOT を付けるのが慣例です。リリース時には -SNAPSHOT を外し、バージョン番号をインクリメントします（例: 1.0, 1.1, 2.0）。

これら3つの要素（groupId, artifactId, version）の組み合わせによって、世界中のあらゆるMavenアーティファクト（ライブラリ、プラグイン、成果物など）が一意に識別されます。

4.4 <packaging>

ビルドされた成果物の種類を指定します。

  • jar: JavaアプリケーションやライブラリのJARファイルを作成します（デフォルト値）。
  • war: WebアプリケーションのWARファイルを作成します。
  • pom: 他のプロジェクトを集約する親プロジェクトなど、ビルド成果物自体は持たないプロジェクトに使用します。
  • maven-plugin: MavenプラグインのJARファイルを作成します。

などがあります。

4.5 <name>, <description>, <url>

プロジェクトの人間が読める名前、簡単な説明、プロジェクトのウェブサイトURLなどを記述します。必須ではありませんが、ドキュメント生成などに利用されます。

4.6 <properties>

プロジェクト内で共通して使用する設定値やバージョンなどを変数として定義できます。変数名は自由に定義できますが、慣例的に something.version や project.something といった形式がよく使われます。pom.xml内で ${変数名} の形式で参照できます。

上記の例では、ソースファイルのエンコーディング(project.build.sourceEncoding)や、Javaのコンパイル対象バージョン(maven.compiler.source, maven.compiler.target)をプロパティとして定義しています。

4.7 <dependencies>

プロジェクトが依存するライブラリ（他のMavenアーティファクト）を定義します。これがMavenの強力な機能の一つである「依存関係管理」の中心です。

<dependencies> 要素の中には、一つ以上の <dependency> 要素を記述します。各 <dependency> 要素は、依存するライブラリのGAV座標を指定します。

例：
xml
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>

この例は、プロジェクトが JUnit というテストライブラリのバージョン 4.11 に依存していることを示しています。

<scope> 要素:
依存関係の利用範囲を指定します。これは非常に重要な要素です。主なスコープは以下の通りです。

  • compile: 最も一般的なスコープです。コンパイル時、テスト時、実行時の全てで必要となる依存関係に使用します。プロジェクトをパッケージングする際にも含まれます。（デフォルトのスコープ）
    • 例: Spring Core, Apache Commons Lang
  • provided: コンパイル時とテスト時には必要ですが、実行時には外部の実行環境（例: WebサーバーのServletコンテナ）によって提供される依存関係に使用します。パッケージング時には含まれません。
    • 例: Servlet API (WARプロジェクトの場合)
  • runtime: コンパイル時には必要ありませんが、実行時およびテスト時には必要となる依存関係に使用します。パッケージング時には含まれます。
    • 例: JDBCドライバ、ロギング実装（Logbackなど）
  • test: テストのコンパイル時と実行時にのみ必要となる依存関係に使用します。本番コードのコンパイル時や、パッケージング時には含まれません。
    • 例: JUnit, Mockito
  • system: Mavenリポジトリからではなく、ローカルのファイルシステム上の特定のパスにあるJARファイルを指定する場合に使用します。<systemPath> 要素でパスを指定する必要があります。このスコープは非推奨であり、特別な理由がない限り使用するべきではありません。
    • 例: 特定のベンダー固有のライブラリで、Mavenリポジトリに存在しないもの
  • import: <dependencyManagement> セクションでのみ使用され、他のPOMの依存関係リストをインポートするために使用します。これは推移的な依存関係には影響しません。主に親POMで子モジュールの依存関係バージョンを一元管理するために使用します。

スコープを適切に設定することで、ビルド成果物に必要なライブラリだけを含めることができ、成果物のサイズを小さく保つことができます。

4.8 <build>

プロジェクトのビルド方法に関する設定を記述します。コンパイル、テスト、パッケージングといった各ビルドフェーズで使用されるプラグインとその設定を定義します。

<build> 要素の中には、<plugins> 要素があり、その中に一つ以上の <plugin> 要素を記述します。

例：
xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
</plugins>
</build>

この例は、Javaコードのコンパイルに Maven Compiler Plugin のバージョン 3.8.0 を使用することを指定し、コンパイル対象のJavaバージョンをプロパティで定義した値 (1.7) に設定しています。

Mavenはデフォルトで多くの標準プラグイン（コンパイラ、テスト実行、JAR作成など）を特定のバージョンで持っていますが、<build> セクションで明示的にプラグインとそのバージョン、設定を記述することで、デフォルト設定を上書きしたり、追加の設定を行ったりすることができます。これにより、プロジェクトの要件に合わせてビルドプロセスをカスタマイズできます。

主要なプラグインの例：

  • maven-compiler-plugin: Javaソースコードをコンパイルします。
  • maven-surefire-plugin: JUnitなどのテストを実行します。
  • maven-jar-plugin: JARファイルを作成します。
  • maven-war-plugin: WARファイルを作成します。
  • maven-install-plugin: ビルド成果物をローカルリポジトリにインストールします。
  • maven-deploy-plugin: ビルド成果物をリモートリポジトリにデプロイします。
  • maven-clean-plugin: ビルドによって生成されたファイルを削除します。

5. Mavenのビルドライフサイクルとフェーズ

Mavenの中心的な概念の一つに「ビルドライフサイクル」があります。これは、プロジェクトをビルドするための手順を標準化したものです。開発者は、Mavenの提供する特定の「フェーズ」名を指定してコマンドを実行するだけで、Mavenが定義された手順に従ってビルドを実行してくれます。

5.1 ライフサイクル、フェーズ、ゴールの関係

  • ライフサイクル (Lifecycle): ビルドプロセスの全体像を定義します。例えば、デフォルトのライフサイクルは、クリーンアップ、コンパイル、テスト、パッケージング、インストール、デプロイといった一連のフェーズから構成されます。
  • フェーズ (Phase): ライフサイクルにおける個々の段階（ステップ）です。各フェーズは特定のタスクを表します（例: compile, test, package）。
  • ゴール (Goal): プラグインが実行する具体的なタスクです。例えば、maven-compiler-plugin の compile ゴールはJavaソースコードをコンパイルします。

Mavenは、フェーズを実行するように指示されると、そのフェーズが属するライフサイクルを特定し、指定されたフェーズまでの全てのフェーズを順番に実行します。そして、各フェーズでは、そのフェーズに紐づけられている（バインドされている）プラグインのゴールを実行します。

5.2 主なビルドライフサイクル

Mavenには主に3つの標準ビルドライフサイクルがあります。

  1. default: プロジェクトのデプロイメントを処理する主要なライフサイクルです。最も頻繁に使用されます。
  2. clean: プロジェクトによって生成されたファイルをクリーンアップ（削除）するためのライフサイクルです。
  3. site: プロジェクトのサイトドキュメント（レポートやAPIドキュメントなど）を作成するためのライフサイクルです。

5.3 defaultライフサイクルの主要フェーズ

defaultライフサイクルには多くのフェーズがありますが、入門者がまず知っておくべき主要なフェーズを以下に示します。実行順に並んでいます。

  • validate: プロジェクトが正しい構造を持ち、全ての情報が必要十分に記述されているか検証します。
  • compile: プロジェクトのメインのソースコード（src/main/java 以下）をコンパイルします。コンパイルされたクラスファイルは target/classes ディレクトリに配置されます。
  • test: プロジェクトのテストソースコード（src/test/java 以下）をコンパイルし、テストを実行します。テスト結果は target/surefire-reports ディレクトリに生成されます。テスト失敗はビルド失敗と見なされます。
  • package: コンパイルされたコードやリソースなどを、pom.xml の <packaging> で指定された形式（JAR, WARなど）にパッケージングします。生成された成果物は target ディレクトリに配置されます。
  • verify: パッケージが有効で品質基準を満たしているか確認するフェーズです。テストの実行もこのフェーズに含まれます。インテグレーションテストなどもここで行われることがあります。
  • install: ビルドされた成果物（JAR/WARファイルなど）と pom.xml を、ローカルリポジトリ（通常は ~/.m2/repository）にインストールします。これにより、他のローカルプロジェクトがこの成果物を依存関係として利用できるようになります。
  • deploy: ビルドされた成果物をリモートリポジトリ（共有リポジトリなど）にコピーします。これにより、他の開発者やCI/CDサーバーなどがこの成果物を利用できるようになります。

5.4 フェーズの実行

Mavenコマンドラインでフェーズ名を指定して実行します。例えば、mvn package を実行すると、Mavenは default ライフサイクルを上から順に実行し、package フェーズに到達するまでの全てのフェーズ（validate, compile, test など）を自動的に実行します。

bash
mvn compile # -> validate, compile を実行
mvn test # -> validate, compile, test を実行
mvn package # -> validate, compile, test, package を実行
mvn install # -> validate, compile, test, package, install を実行
mvn deploy # -> validate, compile, test, package, install, deploy を実行

このように、指定したフェーズまでの全てが実行されるため、通常は目的とするフェーズ（例: package, install）を指定すれば十分です。

clean ライフサイクルのフェーズを実行するには、mvn clean とします。これは target ディレクトリなどを削除します。

複数のフェーズを同時に実行することも可能です。例えば、クリーンしてからインストールを実行するには、以下のように指定します。

bash
mvn clean install

このコマンドは、まず clean ライフサイクルを実行し、次に default ライフサイクルの install フェーズを実行します。

6. Mavenコマンドを使ってみる

Archetypeで作成した my-first-maven-app プロジェクトを使って、基本的なMavenコマンドを実行してみましょう。

プロジェクトルートディレクトリ (my-first-maven-app ディレクトリ) に移動してください。

bash
cd my-first-maven-app

6.1 クリーン (Clean)

ビルドによって生成されたファイル（target ディレクトリなど）を削除します。

bash
mvn clean

実行すると、Mavenがクリーンアップ処理を行い、target ディレクトリが削除されます。

...
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ my-first-maven-app ---
[INFO] Deleting /path/to/my-first-maven-app/target
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

6.2 コンパイル (Compile)

src/main/java 以下のJavaソースコードをコンパイルします。

bash
mvn compile

実行すると、Mavenはまずvalidateフェーズを実行し、次にcompileフェーズを実行します。必要な依存ライブラリ（この場合はJUnitはテストスコープなのでコンパイルには不要ですが、もしコンパイルに必要な依存があれば）をダウンロードし、ソースコードをコンパイルして target/classes ディレクトリに配置します。

...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ my-first-maven-app ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ my-first-maven-app ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /path/to/my-first-maven-app/target/classes
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...
(ArchetypeやMavenのバージョンによって出力内容は異なります)

target/classes ディレクトリを見てみると、コンパイルされた .class ファイルが生成されているのが確認できます。

6.3 テスト (Test)

src/test/java 以下のテストコードをコンパイルし、テストを実行します。

bash
mvn test

このコマンドは、まず validate、compile、test-compile (テストコードのコンパイル) フェーズを実行し、最後に test フェーズでテストを実行します。テスト実行には通常 Maven Surefire Plugin が使用されます。

“`
…
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @ my-first-maven-app —
…
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ my-first-maven-app —
…
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @ my-first-maven-app —
…
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @ my-first-maven-app —
[INFO] Compiling 1 source file to /path/to/my-first-maven-app/target/test-classes
[INFO] — maven-surefire-plugin:2.12.4:test (default-test) @ my-first-maven-app —
[INFO] Surefire report directory: /path/to/my-first-maven-app/target/surefire-reports

T E S T S

Running com.example.app.AppTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
…
“`
(出力内容はArchetypeやMavenのバージョンによって異なります)

テストが実行され、結果が target/surefire-reports ディレクトリにHTMLやXML形式で出力されます。テストが失敗した場合、ビルドはそこで中断されます。

テストをスキップする:
開発中にテストの実行を省略したい場合は、以下のオプションを使用できます。

  • -DskipTests: テストのコンパイルは行いますが、テストの実行をスキップします。
    bash
    mvn package -DskipTests
  • -Dmaven.test.skip=true: テストのコンパイルと実行の両方をスキップします。
    bash
    mvn install -Dmaven.test.skip=true

6.4 パッケージ (Package)

コンパイル済みのクラスファイルやリソースなどをまとめて、pom.xml の <packaging> で指定された形式の成果物を作成します。デフォルトではJARファイルが作成されます。

bash
mvn package

このコマンドは、validate から package までの全てのフェーズを実行します。生成された成果物は target ディレクトリに配置されます。

...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ my-first-maven-app ---
[INFO] Building jar: /path/to/my-first-maven-app/target/my-first-maven-app-1.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

target ディレクトリを見ると、my-first-maven-app-1.0-SNAPSHOT.jar という名前のJARファイルが作成されているのが確認できます。ファイル名には ${artifactId}-${version}.${packaging} という命名規則が適用されます。

6.5 インストール (Install)

ビルドされた成果物をローカルリポジトリにインストールします。

bash
mvn install

このコマンドは、validate から install までの全てのフェーズを実行します。生成されたJARファイルと pom.xml がローカルリポジトリ（通常 ~/.m2/repository）の対応するディレクトリ（例: ~/.m2/repository/com/example/my-first-maven-app/1.0-SNAPSHOT/）にコピーされます。

...
[INFO] --- maven-install-plugin:2.4:install (default-install) @ my-first-maven-app ---
[INFO] Installing /path/to/my-first-maven-app/target/my-first-maven-app-1.0-SNAPSHOT.jar to /Users/yourusername/.m2/repository/com/example/my-first-maven-app/1.0-SNAPSHOT/my-first-maven-app-1.0-SNAPSHOT.jar
[INFO] Installing /path/to/my-first-maven-app/pom.xml to /Users/yourusername/.m2/repository/com/example/my-first-maven-app/1.0-SNAPSHOT/my-first-maven-app-1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

ローカルリポジトリにインストールされた成果物は、他のローカルプロジェクトが依存関係として参照できるようになります。例えば、別のMavenプロジェクトの pom.xml に、このプロジェクトのGAV座標 (com.example, my-first-maven-app, 1.0-SNAPSHOT) を記述すれば、依存として利用できます。

6.6 デプロイ (Deploy)

ビルドされた成果物をリモートリポジトリにデプロイします。これは通常、社内共有リポジトリやMaven Central Repositoryなどに成果物を公開するために使用されます。この操作を行うには、リモートリポジトリの設定（settings.xml や pom.xml に記述）が必要です。入門段階ではまだ実行する必要はありません。

bash
mvn deploy

6.7 よく使うコマンドの組み合わせ

開発サイクルでは、以下のコマンドをよく使用します。

  • mvn clean install: クリーンしてからビルドし、ローカルリポジトリにインストールする。最も一般的なコマンドです。
  • mvn clean package: クリーンしてからビルドし、パッケージを作成する。ローカルリポジトリへのインストールは不要な場合に使います。
  • mvn test: テストだけを実行する。コード変更後に素早くテスト結果を確認したい場合に使います。

7. Mavenリポジトリの仕組み

Mavenの依存関係管理機能は、「リポジトリ」という概念に支えられています。リポジトリは、ライブラリやプラグインといったMavenアーティファクトが保管されている場所です。Mavenは、依存関係を解決するために、これらのリポジトリから必要なアーティファクトを検索し、ダウンロードします。

Mavenが依存関係を検索する主なリポジトリは以下の3種類です。

7.1 ローカルリポジトリ (Local Repository)

  • 場所: ユーザーのホームディレクトリ内の .m2/repository ディレクトリ（例: ~/.m2/repository）。
  • 役割: ダウンロードしたアーティファクトや、自分でビルドしてインストールしたアーティファクトをキャッシュとして保存する場所です。
  • 仕組み: Mavenが依存関係を解決する際、まずこのローカルリポジトリを検索します。ここにアーティファクトがあれば、ネットワークアクセスなしに利用できます。なければ、リモートリポジトリからダウンロードしてローカルリポジトリに保存します。これにより、一度ダウンロードしたアーティファクトは次回以降は高速に利用できます。
  • 内容: ディレクトリ構造はGAV座標に対応しています。例えば、junit:junit:4.11 は ~/.m2/repository/junit/junit/4.11/ の中に junit-4.11.jar や junit-4.11.pom といったファイルとして保存されます。

7.2 セントラルリポジトリ (Maven Central Repository)

  • 場所: https://repo1.maven.org/maven2/
  • 役割: 世界中の多くのオープンソースライブラリが公式に公開されている、Mavenのデフォルトの中央リポジトリです。Mavenをインストールした時点で、特別な設定なしにここからアーティファクトをダウンロードできます。
  • 仕組み: ローカルリポジトリに目的のアーティファクトがない場合、Mavenは次に設定されているリモートリポジトリ（デフォルトではセントラルリポジトリ）を検索します。発見した場合は、ローカルリポジトリにダウンロードしてからビルドに使用します。

7.3 リモートリポジトリ (Remote Repositories)

  • 場所: セントラルリポジトリ以外の、ネットワーク経由でアクセス可能なリポジトリ。
  • 役割: セントラルリポジトリ以外のアーティファクト（例: 組織内のプライベートライブラリ、特定のベンダーのリポジトリなど）をホストします。
  • 種類:
    • 社内リポジトリ: 組織内で開発されたライブラリや、外部ライブラリのミラーなどを配置するために使用します（例: Nexus, Artifactory）。
    • 特定のプロジェクトリポジトリ: 例外的にMaven Central以外で公開されているライブラリのリポジトリ。
  • 設定: pom.xml の <repositories> セクション、またはMavenの設定ファイル settings.xml に記述することで、Mavenがセントラルリポジトリ以外のリモートリポジトリを参照するように設定できます。

Mavenが依存関係を解決する際の検索順序は、基本的に以下のようになります。

  1. ローカルリポジトリを検索。
  2. ローカルになければ、pom.xml や settings.xml で設定されているリモートリポジトリを順番に検索。
  3. リモートリポジトリで見つかったら、ローカルリポジトリにダウンロードして使用。

この仕組みにより、必要なライブラリは自動的にダウンロードされ、ローカルにキャッシュされるため、開発者は手動でのライブラリ管理から解放されます。

8. よく使う設定と便利な機能

8.1 依存関係のバージョンの管理

プロジェクトの規模が大きくなり、多くの依存関係を持つようになると、異なる依存関係が同じライブラリの異なるバージョンに依存している、といった状況が発生しやすくなります。また、複数の依存関係で共通のライブラリ（例: SpringやHibernateなど）を使う場合、バージョンを統一しないと予期せぬ問題が発生することがあります。

これらの問題を解決し、依存関係のバージョンを一元管理するために、以下の方法がよく用いられます。

  1. プロパティの利用: 単純に <properties> でバージョンを定義し、<dependency> で参照します。
    “`xml 5.3.20
    4.13.2



    org.springframework
    spring-core
    ${spring.version}


    org.springframework
    spring-context
    ${spring.version}


    junit
    junit
    ${junit.version}
    test


    ``
    これにより、Springのバージョンを一箇所(    spring.version`プロパティ)で管理できます。

  2. <dependencyManagement> の利用: 親子関係のある複数のモジュールを持つプロジェクト（マルチモジュールプロジェクト）の場合、子モジュール間で依存関係のバージョンを統一するために、親POMの <dependencyManagement> セクションを使用します。
    “`xml
    com.example
    my-multi-module-project
    1.0-SNAPSHOT pom 

    <modules>
    <module>module-a</module>
    <module>module-b</module>
</modules>

<properties>
    <spring.version>5.3.20</spring.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring.version}</version>
            <!-- ここではscopeは指定しないのが一般的 -->
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring.version}</version>
        </dependency>
        <!-- 他の共通依存関係 -->
    </dependencies>
</dependencyManagement>

<!-- ... -->

    “`

    “`xml

    com.example
    my-multi-module-project
    1.0-SNAPSHOT
    ../pom.xml 

    <artifactId>module-a</artifactId>
<!-- versionは親から継承されるので省略可能 -->
<!-- groupIdも親から継承されるので省略可能 -->

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <!-- <version> を省略！バージョンは親の dependencyManagement から解決される -->
    </dependency>
    <!-- module-a固有の依存関係 -->
</dependencies>

<!-- ... -->

    ``に記述された依存関係は、それ自体では依存としてプロジェクトに追加されません。これはあくまで「利用可能な依存関係とその推奨バージョン」のリストです。実際に依存として追加するには、子モジュールのセクションにとを記述する必要があります。その際、を省略すると、親の` で定義されたバージョンが自動的に適用されます。

    この仕組みにより、プロジェクト全体の依存関係のバージョンを親POMで一元管理でき、バージョン間の不整合を防ぐことができます。

8.2 プラグインの設定

Mavenのビルドはプラグインによって行われるため、プラグインの設定を変更することでビルドの挙動をカスタマイズできます。プラグインの設定は <build> -> <plugins> セクションで行います。

例: Javaコンパイラのバージョンを指定する (maven-compiler-plugin)
xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version> <!-- 使用するプラグインのバージョン -->
<configuration> <!-- プラグイン固有の設定 -->
<source>11</source> <!-- ソースコードのJavaバージョン -->
<target>11</target> <!-- バイトコードのJavaバージョン -->
<encoding>UTF-8</encoding> <!-- ソースコードのエンコーディング -->
</configuration>
</plugin>
<!-- 他のプラグイン設定 -->
</plugins>
</build>
<configuration> 要素の中に、プラグインが提供する設定項目を記述します。どのような設定項目があるかは、各プラグインのドキュメントを参照する必要があります。

例: テスト実行時に特定のテストを除外する (maven-surefire-plugin)
xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<excludes>
<exclude>**/ExcludeThisTest.java</exclude>
<exclude>**/integration/**</exclude> <!-- integrationディレクトリ以下のテストを全て除外 -->
</excludes>
</configuration>
</plugin>
</plugins>
</build>

このように、プラグインの設定をカスタマイズすることで、コンパイルオプションの変更、テスト実行方法の調整、パッケージング形式の制御など、ビルドプロセスを細かく制御できます。

8.3 プロファイル (Profiles)

プロファイルは、特定の環境や目的（開発、テスト、本番、OSなど）に応じてビルド設定を切り替えるための機能です。例えば、開発環境ではデバッグ情報を多く含め、本番環境では最適化を有効にする、といった使い分けが可能です。

プロファイルは pom.xml の <profiles> セクションで定義します。

“`xml dev

true
development 

<profile>
    <id>prod</id>
    <properties>
        <build.env>production</build.env>
    </properties>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <debug>false</debug> <!-- プロダクションビルドではデバッグ情報を無効に -->
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

“`

プロファイルをアクティブにするには、コマンドラインで -P オプションを使用します。

bash
mvn package -P prod # prodプロファイルをアクティブにしてパッケージング

プロファイルの活用により、単一の pom.xml ファイルで様々なビルド要件に対応できます。

8.4 マルチモジュールプロジェクト (Multi-module Projects)

大規模なプロジェクトでは、複数のサブプロジェクト（モジュール）に分割することがよくあります。例えば、ビジネスロジック、Webインターフェース、バッチ処理などがそれぞれ独立したモジュールとして開発されるケースです。

Mavenでは、このような構成を「マルチモジュールプロジェクト」として管理できます。マルチモジュールプロジェクトは、成果物を持たない親POM (<packaging>pom</packaging>) と、親POMから継承しつつ独自の成果物を持つ子モジュールPOM (<packaging>jar, <packaging>war など) で構成されます。

親POMは子モジュールを <modules> セクションでリストアップし、子モジュールは <parent> セクションで親POMを指定します。

これにより、親プロジェクトのルートディレクトリでMavenコマンドを実行すると、全ての子モジュールに対してそのコマンドが実行されます（例: mvn clean install を親プロジェクトで実行すると、全ての子モジュールが順番にクリーンされ、ビルドされ、インストールされる）。また、前述の <dependencyManagement> を使って、子モジュール間の依存関係バージョンを一元管理できます。

マルチモジュールプロジェクトは入門段階では必須ではありませんが、ある程度規模の大きなプロジェクトに関わるようになると、この概念は非常に重要になります。

9. トラブルシューティング

Mavenを使用していると、様々なエラーに遭遇することがあります。ここでは、よくある問題とその対処法について説明します。

9.1 ビルドエラー

Mavenのビルドエラーは、多くの原因によって発生します。エラーメッセージを注意深く読むことが解決の第一歩です。

  • コンパイルエラー: Javaのシンタックスエラーやクラスパスの問題など、通常のJava開発におけるコンパイルエラーです。Mavenの出力に表示されるエラーメッセージ（どのファイルの何行目かなど）を参考に、ソースコードを修正します。
  • テスト失敗: mvn test や mvn package/install 実行中にテストが失敗した場合、Mavenはビルドを中断します。Surefire Pluginの出力や、target/surefire-reports ディレクトリに生成されるレポートを確認して、テストコードや本番コードの問題を修正します。
  • 依存関係が見つからない (Could not find artifact …): Mavenが依存関係として指定されたアーティファクトを、ローカルリポジトリや設定されているリモートリポジトリで見つけられなかった場合に発生します。
    • 確認ポイント:
      • pom.xml の groupId, artifactId, version が正しいか確認します。特にバージョン番号のタイプミスが多いです。
      • ローカルリポジトリ (~/.m2/repository) に該当のアーティファクトが存在しないか確認します。もし部分的に存在して壊れている場合は、そのディレクトリを削除して再度ビルドを試みます。
      • Maven Central Repositoryでそのアーティファクトが本当に存在するか検索します (https://search.maven.org/)。
      • もしセントラルリポジトリ以外のリモートリポジトリに依存している場合、そのリポジトリが pom.xml の <repositories> または settings.xml に正しく設定されているか確認します。
      • ネットワーク接続に問題がないか、プロキシ設定 (settings.xml に記述) が必要でないか確認します。
  • プラグインエラー: 特定のプラグインの実行中にエラーが発生します。プラグインのバージョンがプロジェクトのJavaバージョンや他の依存関係と互換性がない、プラグインの設定が間違っている、といった原因が考えられます。
    • 確認ポイント:
      • エラーメッセージに示されているプラグイン名とゴールを確認します。
      • pom.xml のプラグイン設定に間違いがないか確認します。特に <configuration> 内の設定項目名や値を確認します。
      • 使用しているプラグインのバージョンが適切か確認します。可能であれば最新版に更新したり、安定したバージョンに戻したりして試します。
      • 特定のプラグインに関するエラーの場合は、そのプラグインの公式ドキュメントを参照して、よくある問題や設定方法を確認します。

9.2 デバッグ情報の出力

エラーの原因が特定しにくい場合、Mavenのデバッグオプションを有効にすると、より詳細な出力が得られます。

  • -X または --debug: デバッグ出力を有効にします。どのプラグインのどのゴールが実行され、どのような設定が使われているかなどが詳しく表示されます。情報量が非常に多くなりますが、問題特定の強力な手がかりとなります。
    bash
    mvn clean install -X
  • -e または --errors: スタックトレースなど、エラーに関する詳細な情報のみを出力します。-X ほど大量の情報は出ませんが、エラーの原因を特定するのに役立ちます。
    bash
    mvn clean install -e

これらのオプションは、特に依存関係の解決問題やプラグイン関連の問題で役立ちます。

9.3 ローカルリポジトリの問題

ローカルリポジトリのファイルが破損したり、不整合が発生したりすることが稀にあります。

  • ローカルリポジトリのクリーンアップ: 特定のアーティファクトがおかしい場合は、そのアーティファクトのディレクトリをローカルリポジトリから手動で削除し、再度Mavenコマンドを実行してダウンロードし直させます。
  • 強制的な更新: リモートリポジトリの内容が変更されたにも関わらず、ローカルリポジトリのキャッシュが古い場合に問題が発生することがあります。-U または --update-snapshots オプションを付けて実行すると、SNAPSHOTバージョンだけでなく、リリースバージョンも含めてリモートリポジトリから強制的に更新チェックを行います。
    bash
    mvn clean install -U
    SNAPSHOTバージョンのみを更新する場合は、-U オプションは不要です。MavenはデフォルトでSNAPSHOTバージョンの更新チェックを行います。

9.4 IDEとの連携

Eclipse, IntelliJ IDEA, VS CodeなどのモダンなJava向けIDEのほとんどは、Mavenとの強力な連携機能を備えています。IDEにMavenプロジェクトをインポートすると、IDEがpom.xmlを読み込んで依存関係を自動的にダウンロードしたり、IDE上からMavenのビルドフェーズを実行したりできます。

IDE上で問題が発生した場合、まずはコマンドラインで同じMavenコマンドを実行してみて、IDE固有の問題かMaven自体の問題かを切り分けるのが有効です。IDEのMaven設定（Mavenホームディレクトリ、ローカルリポジトリのパスなど）が正しいか確認することも重要です。

10. 次のステップ

これで、Mavenの基本的な概念と使い方を理解し、簡単なプロジェクトを作成・ビルドできるようになりました。これはMaven活用の第一歩に過ぎません。さらにMavenを使いこなすためには、以下のステップに進むことをお勧めします。

  • より複雑なプロジェクトのビルド: WARファイルの作成（packagingをwarに設定し、Maven War Pluginを使用）、実行可能なJARファイルの作成（Maven Shade PluginやMaven Assembly Pluginなどを使用）など、様々な種類の成果物のビルド方法を学ぶ。
  • プラグインの詳細: よく使うプラグイン（Compiler Plugin, Surefire Plugin, JAR Pluginなど）の設定オプションについて、公式ドキュメントを読んで理解を深める。特定の要件に合わせてプラグインを設定できるようになる。
  • マルチモジュールプロジェクト: 複数のモジュールに分割されたプロジェクトの構造、親子のPOMの設定方法、<dependencyManagement> の活用方法などを学ぶ。
  • 高度な依存関係管理: 依存関係の競合の解決 (<exclusions>)、オプショナルな依存関係 (<optional>)、依存関係の範囲 (<scope>) のより深い理解。
  • Maven Settings: settings.xml を使ったローカルリポジトリパスの変更、プロキシ設定、リモートリポジトリ認証、ミラー設定などを学ぶ。
  • カスタムArchetype: 独自のプロジェクトひな形を作成して、新しいプロジェクトを素早く始められるようにする。
  • CI/CDとの連携: Jenkins, GitLab CI, GitHub Actionsなどの継続的インテグレーション/継続的デリバリーツールとMavenを連携させる方法を学ぶ。

Mavenは奥深いツールですが、まずはこの記事で解説した基本的な概念とコマンドをしっかりと理解し、実際に手を動かして様々な種類のプロジェクトをビルドしてみることが重要です。

まとめ

この記事では、Javaプロジェクトのビルド自動化・プロジェクト管理ツールであるMavenについて、その目的、インストール方法、基本的な使い方、主要な概念を詳細に解説しました。

  • Mavenは、依存関係管理、標準プロジェクト構造、標準ビルドプロセスを提供し、Java開発の効率と保守性を大幅に向上させます。
  • pom.xml はプロジェクトの設計図であり、依存関係 (<dependencies>) やビルド設定 (<build>) など、プロジェクトのあらゆる情報が集約されます。
  • GAV座標 (groupId, artifactId, version) は、Mavenアーティファクトを一意に識別するための情報です。
  • ビルドライフサイクル（default, clean, site）は、標準的なビルド手順を定義しており、compile, test, package, install などのフェーズを実行することでビルドが進みます。
  • Mavenはローカルリポジトリ、セントラルリポジトリ、リモートリポジトリから依存ライブラリを自動的に解決・ダウンロードします。
  • プロパティや<dependencyManagement> を使ったバージョン管理、プラグイン設定によるビルドのカスタマイズ、プロファイルを使った環境ごとの設定切り替えなどが可能です。

MavenはJava開発者にとって必須のスキルです。この記事が、皆様のMaven学習の強力な一助となれば幸いです。是非、実際に手を動かして、Mavenの便利さを体感してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール