TOC

Apache Mavenチュートリアル

1前書き

ソフトウェアプロジェクトの構築は通常、依存関係のダウンロード、クラスパスへのjarの追加、ソースコードのバイナリコードへのコンパイル、テストの実行、コンパイル済みコードのJAR、WAR、ZIPファイルなどのデプロイ可能なアーティファクトへのパッケージ化、およびこれらのアーティファクトのデプロイなどのタスクで構成されます。アプリケーションサーバーまたはリポジトリへ。

Apache Maven はこれらの作業を自動化し、ソフトウェアを手動で構築しながらコードを作成する作業からコードをコンパイルしてパッケージ化する作業を分離しながら、人がエラーを犯すリスクを最小限に抑えます。

このチュートリアルでは、XMLで書かれた中心的な情報である Project Object Model （POM）を使用して、Javaソフトウェアプロジェクトを記述、構築、および管理するためのこの強力なツールを探ります。

** 2 Mavenを使用する理由

Mavenの主な機能は以下のとおりです。

  • ベストプラクティスに従った簡単なプロジェクト設定: Mavenは

プロジェクトテンプレートを提供することによって、できるだけ多くの設定を避ける （名前は archetypes ） 依存関係管理:** 自動更新、ダウンロードを含む

互換性を検証し、依存関係を報告する クロージャー（推移的依存関係とも呼ばれる） プロジェクトの依存関係とプラグインの分離:** Mavenを使って、

プロジェクトの依存関係は dependency repositories から取得されます。 プラグインの依存関係は pluginから取得されます。 リポジトリ、 プラグインの起動時に競合が少なくなる 追加の依存関係をダウンロードする 中央リポジトリシステム:** プロジェクトの依存関係は、から読み込むことができます。

ローカルファイルシステムまたはパブリックリポジトリ（https://search.maven.org/classic/[Maven Central]など）

  • あなたのシステムにMavenをインストールする方法を学ぶために、リンクをチェックしてください:/install-maven-on-windows-linux-mac[このチュートリアルBaeldung]

3プロジェクトオブジェクトモデル

Mavenプロジェクトの設定は、 pom.xml ファイルで表される Project Object Model（POM） を介して行われます。 POM はプロジェクトを記述し、依存関係を管理し、そしてソフトウェアを構築するためのプラグインを設定します。

POM は、マルチモジュールプロジェクトのモジュール間の関係も定義します。典型的な POM ファイルの基本構造を見てみましょう: 

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
           //...
            </plugin>
        </plugins>
    </build>
</project>

これらの構成要素を詳しく見てみましょう。

3.1. プロジェクト識別子

Mavenは、プロジェクトを一意に識別し、プロジェクト成果物をパッケージ化する方法を指定するために、座標とも呼ばれる一連の識別子を使用します。

  • groupId - 作成した会社またはグループの固有の基本名

プロジェクト ** artifactId - プロジェクトの一意の名前

  • version - プロジェクトのバージョン

  • packaging - パッケージ方法（例: WAR / JAR / ZIP ）

これらのうち最初の3つ（ groupId:artifactId:version ）は、一意の識別子を形成するために組み合わされ、プロジェクトが使用する外部ライブラリ（JARなど）のバージョンを指定するメカニズムです。

3.2. 依存関係

プロジェクトが使用するこれらの外部ライブラリは依存関係と呼ばれます。

Mavenの依存関係管理機能は、中央のリポジトリからそれらのライブラリを自動的にダウンロードするので、ローカルに保存する必要はありません。

これはMavenの重要な機能であり、次のような利点があります。

  • ** ダウンロード数を大幅に減らすことで、使用するストレージを少なくします。

リモートリポジトリをオフにする プロジェクトのチェックアウトが速くなります

  • ** 内でバイナリ成果物を交換するための効果的なプラットフォームを提供します。

毎回ソースからアーティファクトを構築する必要なしにあなたの組織およびそれ以降

外部ライブラリへの依存関係を宣言するには、ライブラリの groupId、artifactId 、および version を提供する必要があります。

例を見てみましょう。 

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.3.5.RELEASE</version>
</dependency>

Mavenが依存関係を処理すると、Spring CoreライブラリがローカルのMavenリポジトリにダウンロードされます。

3.3. リポジトリ

Mavenのリポジトリーは、ビルド成果物およびさまざまなタイプの依存関係を保持するために使用されます。デフォルトのローカルリポジトリは、ユーザのホームディレクトリの下の .m2/repository フォルダにあります。

アーティファクトまたはプラグインがローカルリポジトリで利用可能な場合、Mavenはそれを使用します。それ以外の場合は、中央リポジトリからダウンロードされてローカルリポジトリに保存されます。デフォルトのセントラルリポジトリはhttps://search.maven.org/classic/#search%7Cga%7C1%7Ccentra[Maven Central]です。

JBossサーバーなどの一部のライブラリは、中央リポジトリでは利用できませんが、代替リポジトリでは利用できます。これらのライブラリの場合は、 pom.xml ファイル内の代替リポジトリへのURLを提供する必要があります。 

<repositories>
    <repository>
        <id>JBoss repository</id>
        <url>http://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

プロジェクトでは複数のリポジトリを使用できることに注意してください。

3.4. プロパティ

カスタムプロパティを使用すると、 pom.xml ファイルを読みやすく管理しやすくなります。従来のユースケースでは、プロジェクトの依存関係のバージョンを定義するためにカスタムプロパティを使用します。

  • Mavenプロパティは値プレースホルダであり、 $ \ {name} ** という表記法を使用して pom.xml内の任意の場所からアクセスできます。ここで、 name__はプロパティです。

例を見てみましょう。 

<properties>
    <spring.version>4.3.5.RELEASE</spring.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>
</dependencies>

Springを新しいバージョンにアップグレードしたい場合は、 __ <spring.version> プロパティタグ内の値を変更するだけでよく、その <version> __タグでそのプロパティを使用するすべての依存関係が更新されます。

プロパティは、ビルドパス変数を定義するためにもよく使われます。 

<properties>
    <project.build.folder>${project.build.directory}/tmp/</project.build.folder>
</properties>

<plugin>
   //...
    <outputDirectory>${project.resources.build.folder}</outputDirectory>
   //...
</plugin>

3.5. ビルド

build セクションもMaven POMの非常に重要なセクションです。このセクションには、デフォルトのMaven goal 、コンパイル済みプロジェクトのディレクトリ、およびアプリケーションの正式名に関する情報が記載されています。デフォルトの build__セクションは次のようになります。 

<build>
    <defaultGoal>install</defaultGoal>
    <directory>${basedir}/target</directory>
    <finalName>${artifactId}-${version}</finalName>
    <filters>
      <filter>filters/filter1.properties</filter>
    </filters>
   //...
</build>

  • コンパイル済み成果物のデフォルトの出力フォルダーは target であり、パッケージ化成果物の最終名は artifactId と version で構成されていますが、いつでも変更できます。

3.6. Profiles を使う

Mavenのもう1つの重要な機能は、 profilesのサポートです。 profile は基本的に一連の設定値です。 profiles を使用すると、本番/テスト/開発などのさまざまな環境に合わせてビルドをカスタマイズできます。 

<profiles>
    <profile>
        <id>production</id>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
    </profile>
    <profile>
        <id>development</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
     </profile>
 </profiles>

上の例からわかるように、デフォルトのプロファイルは development に設定されています。 production profile を実行したい場合は、次のMavenコマンドを使用できます。 

mvn clean install -Pproduction

4 Maven Buildライフサイクル

すべてのMavenビルドは指定された ライフサイクル に従います。ローカルのMaven依存関係リポジトリに、プロジェクトのコードをコンパイルし、アーカイブファイルを作成し、インストールファイルを作成するためのビルドを含む、いくつかのビルドライフサイクルを実行することができます。

4.1. ライフサイクルフェーズ

以下のリストは、最も重要なMavenのライフサイクルフェーズを示しています。

  • validate - プロジェクトの正当性をチェックします

  • compile - 提供されたソースコードをバイナリ成果物にコンパイルします。

  • test - 単体テストを実行する

  • package - コンパイル済みコードをアーカイブファイルにパッケージ化する

  • integration-test - 追加のテストを実行します。

包装 ** verify - パッケージが有効かどうかを調べる

  • install - パッケージファイルをローカルのMavenリポジトリにインストールします

  • deploy - パッケージファイルをリモートサーバーまたはリポジトリにデプロイします。

4.2. Plugins と Goals

Maven plugin は1つ以上の goals の集合です。目標は段階的に実行され、 goals が実行される順序を決定するのに役立ちます。

Mavenによって公式にサポートされているプラ​​グインの豊富なリストはhttps://maven.apache.org/plugins/[here]にあります。 ** 様々なプラグインを使ってリンクする方法:/executable-jar-with-maven[実行可能ファイル JAR をBaeldung上に構築する]も興味深い記事があります。

どの goals がデフォルトでどのフェーズで実行されているかをよりよく理解するために、http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in Lifecycle Bindings[defaultを見てください。 Maven ライフサイクル バインディング]。

上記のフェーズのいずれかを通過するには、1つのコマンドを呼び出すだけです。 

mvn <phase>

たとえば、 mvn clean install は、以前に作成したjar/war/zipファイルとコンパイル済みクラス（ clean） を削除し、新しいアーカイブのインストールに必要なすべてのフェーズ（ install） を実行します。

  • plugins が提供する goals は、 lifecycle のさまざまなフェーズに関連付けることができます。

5あなたの最初のMavenプロジェクト

このセクションでは、Mavenのコマンドライン機能を使用してJavaプロジェクトを作成します。

5.1. 単純なJavaプロジェクトの生成

単純なJavaプロジェクトを構築するために、次のコマンドを実行しましょう。 

mvn archetype:generate
  -DgroupId=org.baeldung
  -DartifactId=org.baeldung.java
  -DarchetypeArtifactId=maven-archetype-quickstart
  -DinteractiveMode=false

groupId は、プロジェクトを作成したグループまたは個人を示すパラメータです。これは、多くの場合、逆の会社のドメイン名です。 artifactId はプロジェクトで使用される基本パッケージ名であり、標準の archetype を使用します。

バージョンとパッケージタイプを指定していないため、これらはデフォルト値に設定されます。バージョンは 1.0-SNAPSHOT、 に設定され、パッケージは jar に設定されます。

  • 提供するパラメータがわからない場合は、 __interactiveMode = true__を常に指定できるので、Mavenは必要なすべてのパラメータを要求します。

コマンドが完了すると、 src/main/java フォルダーに App.java クラスが含まれたJavaプロジェクトが作成されます。これは単純な「Hello World」プログラムです。

src/test/java にテストクラスの例もあります。このプロジェクトの pom.xml は、次のようになります。 

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung.java</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung.java</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.1.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

ご覧のとおり、 junit 依存関係はデフォルトで提供されています。

5.2. プロジェクトのコンパイルとパッケージング

次のステップはプロジェクトをコンパイルすることです。 

mvn compile

Mavenは、プロジェクトのソースを構築するために compile フェーズに必要なすべての lifecycle フェーズを実行します。 test フェーズのみを実行したい場合は、次のものを使用できます。 

mvn test

それでは、コンパイルされたアーカイブ jar ファイルを生成する package フェーズ __、 __を呼び出しましょう。 

mvn package

5.3. アプリケーションの実行

最後に、 exec-maven-plugin を使ってJavaプロジェクトを実行します。必要なプラグインを pom.xml に設定しましょう。 

<build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.6.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.5.0</version>
            <configuration>
                <mainClass>org.baeldung.java.App</mainClass>
            </configuration>
        </plugin>
    </plugins>
</build>

最初のプラグインhttps://search.maven.org/classic/#search%7Cga%7C1%7Ca%3A%22maven-compiler-plugin%22[ maven-compiler-plugin ]は、次のコードを使用してコンパイルします。 Javaバージョン1.8 exec-maven-plugin は、私たちのプロジェクトで mainClass を検索します。

アプリケーションを実行するために、次のコマンドを実行します。 

mvn exec:java

6. マルチモジュールプロジェクト

Mavenでマルチモジュールプロジェクト（ aggregator プロジェクトとも呼ばれる）を処理するメカニズムは Reactor と呼ばれます。

Reactor はビルドするために利用可能なすべてのモジュールを集め、それからプロジェクトを正しいビルド順にソートし、そして最後にそれらを一つずつビルドします。

マルチモジュールの親プロジェクトを作成する方法を見てみましょう。

6.1. 親プロジェクトを作成

まず最初に、親プロジェクトを作成する必要があります。 parent-projectという名前の新しいプロジェクトを作成するには、 次のコマンドを使用します。 

mvn archetype:generate -DgroupId=org.baeldung -DartifactId=parent-project

次に、 pom.xml ファイル内のパッケージタイプを更新して、これが parent モジュールであることを示します。 

<packaging>pom</packaging>

6.2. サブモジュールプロジェクトを作成する

次のステップでは、 parent-project のディレクトリからサブモジュールプロジェクトを作成します。 

cd parent-project
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=core
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=service
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=webapp

サブモジュールが正しく作成されたかどうかを確認するために、 parent-project pom.xml ファイルを調べます。ここで、3つのモジュールが表示されます。 

<modules>
    <module>core</module>
    <module>service</module>
    <module>webapp</module>
</modules>

さらに、各サブモジュールの pom.xml に親セクションが追加されます。 

<parent>
    <groupId>org.baeldung</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>

6.3. 親プロジェクトで依存関係管理を有効にする

依存関係管理は、マルチモジュール親プロジェクトとその子の依存関係情報を一元管理するためのメカニズムです。

共通の親を継承する一連のプロジェクトまたはモジュールがある場合は、依存関係について必要なすべての情報を共通の pom.xml ファイルに入れることができます。これは、子 __POM __s内の成果物への参照を単純化します。

親のpom.xmlのサンプルを見てみましょう。 

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>4.3.5.RELEASE</version>
        </dependency>
       //...
    </dependencies>
</dependencyManagement>

親で spring-core バージョンを宣言することによって、 spring-core に依存するすべてのサブモジュールは、 groupId と artifactId のみを使用して依存関係を宣言でき、バージョンは継承されます。 

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
    </dependency>
   //...
</dependencies>

さらに、特定のライブラリが子モジュールに継承されないように、親の pom.xml で依存関係管理の除外を指定できます。 

<exclusions>
    <exclusion>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
    </exclusion>
</exclusions>

最後に、子モジュールが異なるバージョンの管理対象依存関係を使用する必要がある場合は、子の pom.xml ファイルで管理対象バージョンを上書きできます。 

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.2.1.RELEASE</version>
</dependency>

  • 子モジュールは親プロジェクトから継承しますが、親プロジェクトは必ずしもそれが集約するモジュールを持っているわけではありません。一方、親プロジェクトは、それから継承しないプロジェクトを集約することもできます。

継承と集約の詳細については、https://maven.apache.org/pom.html#Aggregation[この文書を参照してください]。

6.4. サブモジュールの更新とプロジェクトの構築

各サブモジュールの packaging タイプを変更できます。たとえば、 pom.xml ファイルを更新して、 webapp モジュールの packaging を WAR に変更します。 

<packaging>war</packaging>

これで、 mvn clean install コマンドを使用してプロジェクトのビルドをテストできます。 Mavenログの出力は次のようになります。 

----[INFO]Scanning for projects...[INFO]Reactor build order:[INFO]  parent-project[INFO]  core[INFO]  service[INFO]  webapp//.............[INFO]-----------------------------------------[INFO]Reactor Summary:[INFO]-----------------------------------------[INFO]parent-project .................. SUCCESS[2.041s][INFO]core ............................ SUCCESS[4.802s][INFO]service ......................... SUCCESS[3.065s][INFO]webapp .......................... SUCCESS[6.125s][INFO]-----------------------------------------
----

7. 結論

この記事では、Apache Mavenビルド・ツールのより一般的な機能について説明しました。

Baeldungのすべてのコード例はMavenを使用して構築されているので、さまざまなMavenの設定を確認するためにhttps://github.com/eugenp/tutorials/tree/master/maven[GitHubプロジェクトのWebサイト]を簡単に確認できます。

Related