1. 概要

複雑なプロジェクトを手動で構築するのは非常に面倒です。 ビルドツールを使用してこれを行うためのはるかに簡単な方法があります。  ご存知のように、Javaプロジェクトの主要なビルドツールの1つはMavenです。 Mavenは、アプリケーションのビルドとデプロイメントの標準化を支援します。

このチュートリアルでは、Mavenアーティファクトとは何か、およびその主要な要素は何かについて説明します。 また、Mavenの座標、依存関係の管理、そして最後にMavenリポジトリーについても見ていきます。

2. Mavenとは何ですか?

Mavenを使用して、Javaベースのプロジェクトをビルドおよび管理できます。 次のような多くの機能を提供します。

  • 構築とコンパイル
  • ドキュメントとレポート
  • 依存関係の管理
  • ソース管理
  • プロジェクトの更新
  • 展開

各Mavenプロジェクトには、独自のPOMファイルがあります。 1つのプロジェクトまたは複数のプロジェクトをビルドするようにMavenを構成できます。

マルチプロジェクトは通常、ルートディレクトリにPOMファイルを定義し、モジュールセクションに個々のプロジェクトを一覧表示します。 つまり、Mavenビルドは1つ以上のアーティファクトを生成します。

3. Mavenアーティファクトとは何ですか?

アーティファクトは、プロジェクトが使用または生成できる要素です。 Mavenの用語では、 アーティファクト Mavenプロジェクトのビルド後に生成される出力です。 たとえば、 戦争 、またはその他の実行可能ファイル。

また、Mavenアーティファクトには、 groupId ArtifactId version packages 、およびclassifierの5つの主要な要素が含まれます。 これらは、アーティファクトを識別するために使用する要素であり、Maven座標として知られています。

4. Maven座標

Maven座標は、特定のアーティファクトのgroupId、artifactId、およびバージョンの値の組み合わせです。 さらに、Mavenは座標を使用して、次の値に一致するコンポーネントを検索します。 groupId、artifactId、バージョン

座標要素の中で、 groupId ArtifactId 、 とバージョン 。 The 包装要素はオプションであり、直接定義することはできません分類子

たとえば、以下の pom.xml 構成ファイルは、Maven座標の例を示しています。

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung.java</artifactId>
    <packaging>jar</packaging>
    <version>1.0.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>

Mavenの各座標を詳しく見ていきましょう。

4.1. groupId要素

groupId要素は、プロジェクトの起点にあるグループの識別子です。 このキーを使用すると、プロジェクトの整理と検索が簡単かつ迅速になります。

また、 groupId はJavaパッケージと同じ命名規則に従い、通常、groupIdとしてプロジェクトの最上位パッケージの名前を選択します。

たとえば、org.apache.commonsgroupIdは、 $ {repository_home} / org / apache/commonsに対応します。

4.2. ArtifactId要素

ArtifactId要素は、グループ内のプロジェクトの識別子です。 デフォルトでは、アーティファクトの最終的な名前を作成するために使用されます。 したがって、この名前は、理想的には長さが小さいはずなので、いくつかの仕様があります。 ArtifactId に名前を付けるためのベストプラクティスは、実際のプロジェクト名をプレフィックスとして使用することです。 これの利点は、アーティファクトを見つけやすくなることです。

groupId と同様に、 ArtifactId は、groupIdを表すディレクトリツリーの下のサブディレクトリとして表示されます。

たとえば、 org.apache.commons、groupIdの下にあるcommons-lang3artifactIdは、アーティファクトが下にあると判断します。 : $ {repository_home} / org / apache / commons / commons-lang3/

4.3. バージョン要素

バージョンは、アーティファクトの識別子の一部として使用されます。 Mavenプロジェクトの現在のバージョンを定義します。 Mavenは、後で説明するリリースとスナップショットの概念だけでなく、一連のバージョン仕様を定義していることに注意してください。

version は、groupIdartifactIdによって形成されるディレクトリツリーのサブディレクトリとして表されます。

たとえば、org.apache.commonsgroupIdの下にあるartifactIdcommons-lang33.1.1のバージョンは次のように決定します。アーティファクトが次の場所にあること: $ {repository_home} /org/apache/commons/commons-lang3/3.1.1/.

4.4. パッケージング要素

この要素は、プロジェクトによって生成されるアーティファクトのタイプを指定するために使用されます。 パッケージは、 ZIP、EAR、WAR、SWC、NAR、SWF、SARなどの任意のバイナリソフトウェア形式を表すものであれば何でもかまいません。

また、 packages は、プロジェクトのデフォルトのライフサイクル中に実行するさまざまな目標を定義します。 たとえば、パッケージフェーズでは、jarタイプのアーティファクトに対して jar:jar ゴールを実行し、warタイプのアーティファクトに対して war:warゴールを実行します。

4.5. 分類子要素

通常、同じコードを配信するときに技術的な理由で分類子を使用しますが、いくつかの個別のアーティファクトとして使用します

たとえば、 JAR の2つのアーティファクトを異なるJavaコンパイラでビルドする場合、分類子を使用すると、同じもので2つの異なるアーティファクトを簡単に作成できます。 groupId:artifactId:versionの組み合わせ。

また、ソースコード、アーティファクトのJavaDocをパッケージ化するとき、またはバイナリを組み立てるときに、分類子を使用できます。

上記のcommons-lang3の例では、検索するアーティファクトはcommons-lang3-3.10-javadoc.jarまたはcommons-lang3-3.10-sources.jarです。 $ {repository_home}/org/apache/commons/commons-lang3/3.1.0/.の下

5. リリース対。 スナップショットアーティファクト

それでは、スナップショットアーティファクトとリリースアーティファクトの違いを見てみましょう。

5.1. アーティファクトをリリースする

A リリースアーティファクトは、バージョンが安定していることを示します 統合テスト、顧客認定、試作などの開発プロセスの外部で使用できます、など。

また、 リリースアーティファクトは一意です。 の実行 mvn 配備コマンドはプロジェクトをリポジトリにデプロイします。 ただし、同じバージョンの同じプロジェクトで同じコマンドを後で実行すると、失敗します。

5.2. スナップショットアーティファクト

スナップショットアーティファクトは、プロジェクトが開発中であることを示しています。 コンポーネントをインストールまたは公開するとき、Mavenはversion属性をチェックします。 文字列「SNAPSHOT」が含まれている場合、MavenはこのキーをUTC(協定世界時)形式の日付と時刻の値に変換します。

たとえば、プロジェクトがバージョン1.0-SNAPSHOTであり、そのアーティファクトをMavenリポジトリにデプロイする場合、2022年2月19日の23:08 UTCにデプロイすると仮定すると、Mavenはこのバージョンを「1.0-202202019-230800」に変換します。

つまり、スナップショットを展開する場合、ソフトウェアコンポーネントは配信せず、スナップショットのみを配信します。

6. 依存関係の管理

依存関係の管理は、Mavenの世界では不可欠です。 たとえば、プロジェクトがその運用プロセス(コンパイル、実行)で他のクラスに依存している場合、これらの依存関係を識別して、リモートリポジトリからローカルリポジトリにインポートする必要があります。 したがって、プロジェクトはこれらのライブラリに依存し、最終的にプロジェクトのクラスパスに追加されます。

さらに、Mavenの依存関係管理は、いくつかの概念に基づいています。

  • リポジトリ:アーティファクトを保存するために不可欠
  • スコープ:依存関係を使用するコンテキストを指定できます
  • 推移性:依存関係の依存関係を管理できます
  • 継承:親から継承するPOMは、version属性なしで依存関係のgroupIdおよびartifactIdのみを提供することにより、依存関係を設定できます。 Mavenは、親POMファイルから適切なバージョンを取得します。

Mavenでは、依存関係の管理はpom.xmlを介して行われます。 たとえば、Mavenプロジェクトの依存関係宣言は次のようになります。

<dependencies>
    <dependency>
        <groupId>org.apache.maven</groupId>
        <artifactId>maven-plugin-api</artifactId>
        <version>3.8.4</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.15</version>
    </dependency>
</dependencies>

7. Mavenリポジトリ

Mavenはリポジトリを使用して、プロジェクトのビルドに必要な依存関係やプラグインなどの要素を格納します。 これにより、これらの要素を一元化することが可能になります。これらの要素は、通常、いくつかのプロジェクトで使用されます。

前述したように、リポジトリは一連の座標を使用してアーティファクトを格納します: groupId ArtifactId version 、およびpackages。 さらに、Mavenは特定のディレクトリ構造を使用してリポジトリのコンテンツを整理し、必要な要素を見つけられるようにします: $ {repository_home} / groupId / ArtifactId /version

たとえば、このPOM構成について考えてみましょう。

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.baeldung</groupId>
    <artifactId>myApp</artifactId>
    <version>1.0.0</version>
</project>

上記の構成では、プロジェクトは $ {repository_home}/com/baeldung/myApp/1.0.0/パスのリポジトリに保存されます。

8. 結論

この記事では、Mavenアーティファクトの概念とその座標系について説明しました。 また、依存関係やリポジトリなどの関連する概念についても学びました。