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サイト]を簡単に確認できます。