アパッチメイヴン

アパッチメイヴン

開発者	Apacheソフトウェア財団
初回リリース	2004年7月13日; 20年前 ( 2004-07-13 )
安定版リリース	3.9.9 [1]  / 2024年8月18日; 3か月前 （2024年8月18日）
リポジトリ	github.com/apache/maven
書かれた	ジャワ
タイプ	ビルドツール
ライセンス	Apache ライセンス 2.0
Webサイト	翻訳元:

Maven は、主にJavaプロジェクトで使用されるビルド自動化ツールです。Maven は、 C#、Ruby、Scala、その他の言語で記述されたプロジェクトのビルドと管理にも使用できます。Maven プロジェクトは、以前はJakarta プロジェクトの一部であったApache Software Foundationによってホストされています。

Maven は、ソフトウェアの構築方法とその依存関係という、ソフトウェア構築の 2 つの側面に対処します。Apache Antなどの以前のツールとは異なり、ビルド手順には規則を使用します。例外のみを指定する必要があります。XMLファイルには、構築されるソフトウェア プロジェクト、他の外部モジュールやコンポーネントへの依存関係、ビルド順序、ディレクトリ、必要なプラグインが記述されます。コードのコンパイルやパッケージ化など、明確に定義された特定のタスクを実行するための定義済みターゲットが付属しています。Maven は、Maven 2 Central Repository などの 1 つ以上のリポジトリからJavaライブラリと Maven プラグインを動的にダウンロードし、ローカル キャッシュに保存します。^{[2]ダウンロードされた}成果物のこのローカル キャッシュは、ローカル プロジェクトによって作成された成果物で更新することもできます。パブリック リポジトリも更新できます。

Mavenはプラグインベースのアーキテクチャを使用して構築されており、標準入力を介して制御可能な任意のアプリケーションを利用できます。Maven 2ではC / C++ネイティブプラグインが維持されています。^[3]

ビルドツールとしてのGradleやsbtなどの代替技術はXMLに依存しませんが、Mavenが導入した主要な概念を維持しています。Apache Ivyでは、Mavenリポジトリもサポートする専用の依存関係マネージャーも開発されました。^[4]

Apache Mavenは再現可能なビルドをサポートしています。^{[5] [6]}

Maven は 2002 年に Jason van Zyl によって作成され、 Apache Turbineのサブプロジェクトとして始まりました。2003 年に Maven はApache Software Foundation のトップレベルプロジェクトとして承認されました。

バージョン履歴:

• バージョン 1 - 2004 年 7 月 - 最初の重要なマイルストーン リリース (現在はサポート終了)。
• バージョン 2 - 2005 年 10 月 - ベータ サイクルで約 6 か月経過 (現在はサポート終了)。
• バージョン 3 (2010 年 10 月) は、Maven 2 プロジェクトとの下位互換性がほぼ維持されています。変更には、コア プロジェクト ビルダーの再構築と並列ビルドのサポートが含まれます。コアの再構築により、ファイルベースとメモリ内表現が分離され、アドオンが非 XML ベースのプロジェクト定義ファイルを活用できるようになりました。提案されている言語には、Ruby (Jason van Zyl によるプライベート プロトタイプが既に存在)、YAML、およびGroovyが含まれます。並列ビルド機能は、マルチコア マシン上の構成可能な数のコアを活用し、特に大規模なマルチモジュール プロジェクトに適しています。
• バージョン 4 - 現在ベータ開発中 (2024 年 5 月現在)。

Maven プロジェクトは、ファイル内のプロジェクト オブジェクト モデル (POM) を使用して構成されますpom.xml。

サンプルファイル:

<project> 
<!-- Maven 2.x POM の場合、モデル バージョンは常に 4.0.0 です --> <modelVersion> 4.0.0 </modelVersion> <!-- プロジェクト座標、つまりこのプロジェクトを一意に識別する値のグループ --> <groupId> com.mycompany.app </groupId> <artifactId> my-app </artifactId> <version> 1.0 </version>  
  
  
  
  
  
  

  <!-- ライブラリの依存関係 --> 
<依存関係>  

      <!-- 必要なライブラリの座標。
           スコープは 'test' で、ライブラリ
           がテストの実行にのみ使用されることを示します。 --> 
<dependency> <groupId> org.junit.jupiter </groupId> <artifactId> junit-jupiter-engine </artifactId> <version> 5.9.1 </version> <scope> test </scope> </dependency>      
          
          
          
          
      

  </依存関係> 
</プロジェクト>

この POM は、プロジェクトの一意の識別子 (座標) と、 JUnitライブラリへの単一の依存関係を定義します。ただし、プロジェクトをビルドし、プロジェクトに関連付けられた単体テストを実行するには、これで十分です。Maven は、設定よりも規約の考え方を取り入れることでこれを実現します。つまり、Maven はプロジェクトの設定にデフォルト値を提供します。

通常の慣用的なMaven プロジェクトのディレクトリ構造には、次のディレクトリ エントリがあります。

このコマンドは、mvn packageすべての Java ファイルをコンパイルし、テストを実行し、成果物コードとリソースをパッケージ化しますtarget/my-app-1.0.jar(artifactId が my-app で、バージョンが 1.0 であると想定)。

Maven を使用すると、ユーザーはプロジェクトの構成のみを提供し、構成可能なプラグインはプロジェクトのコンパイル、ターゲット ディレクトリのクリーンアップ、ユニット テストの実行、API ドキュメントの生成などの実際の作業を実行します。一般に、ユーザーがプラグインを自分で記述する必要はありません。これとは対照的に、Antとmakeでは、前述のタスクを実行するための命令型のプロシージャを記述します。

プロジェクトオブジェクトモデル（POM）^[7]は、単一のプロジェクトのすべての構成を提供します。一般的な構成では、プロジェクトの名前、所有者、および他のプロジェクトへの依存関係がカバーされます。また、プラグインとして実装されているビルドプロセスの個々のフェーズを構成することもできます。たとえば、コンパイルにJavaバージョン1.5を使用するようにコンパイラプラグインを構成したり、一部のユニットテストが失敗してもプロジェクトをパッケージ化するように指定したりできます。

大規模なプロジェクトは、それぞれ独自の POM を持つ複数のモジュールまたはサブプロジェクトに分割する必要があります。その後、ルート POM を記述して、1 つのコマンドですべてのモジュールをコンパイルできます。POM は他の POM から構成を継承することもできます。すべての POM は、デフォルトでスーパー POM ^[8]から継承します。スーパー POM は、デフォルトのソース ディレクトリ、デフォルトのプラグインなどのデフォルトの構成を提供します。

Mavenの機能のほとんどはプラグインにあります。プラグインはコマンドを使用して実行できる一連のゴールを提供しますmvn [plugin-name]:[goal-name]。たとえば、Javaプロジェクトは、を実行することでコンパイラプラグインのコンパイルゴール^[9]mvn compiler:compileを使用してコンパイルできます。

Mavenプラグインには、ビルド、テスト、ソース管理、Webサーバーの実行、Eclipseプロジェクトファイルの生成など、さまざまな機能があります。^[10]プラグインは、ファイルの<plugins>セクションで導入および構成されますpom.xml。いくつかの基本的なプラグインは、すべてのプロジェクトにデフォルトで含まれており、適切なデフォルト設定になっています。

しかし、ソフトウェア プロジェクトの構築、テスト、パッケージ化という典型的なビルド シーケンスで、それぞれの目標を手動で実行する必要がある場合は面倒です。

• mvn compiler:compile
• mvn surefire:test
• mvn jar:jar

Maven のライフサイクル概念がこの課題に対処します。

プラグインはMavenを拡張する主な方法です。Mavenプラグインの開発は、org.apache.maven.plugin.AbstractMojoクラスを拡張することで行うことができます。アプリケーションサーバーを実行するクラウドベースの仮想マシンを作成するためのMavenプラグインのサンプルコードと説明は、記事「クラウド仮想マシンの開発と管理の自動化」に記載されています。^[11]

ビルドライフサイクルは、目標の実行に順序を与えるために使用できる名前付きフェーズのリストです。Mavenの3つの標準ライフサイクルの1つはデフォルトライフサイクルで、次のフェーズがリストされた順序で実行されます。^[12]

• 検証する
• ソースを生成する
• プロセスソース
• リソースを生成する
• プロセスリソース
• コンパイル
• プロセステストソース
• プロセステストリソース
• テストコンパイル
• テスト
• パッケージ
• インストール
• 展開する

プラグインによって提供されるゴールは、ライフサイクルのさまざまなフェーズに関連付けることができます。たとえば、デフォルトでは、ゴールはフェーズcompiler:compileに関連付けられcompile、ゴールはフェーズsurefire:testに関連付けられますtest。mvn testコマンドが実行されると、Maven は フェーズまでの各フェーズに関連付けられたすべてのゴールを実行しますtest。このような場合、Maven はフェーズresources:resourcesに関連付けられたゴールを実行しprocess-resources、次に を実行compiler:compileし、最終的にゴールを実行するまでこれを繰り返しますsurefire:test。

Maven には、プロジェクトをクリーンアップし、プロジェクト サイトを生成するための標準フェーズもあります。クリーンアップがデフォルトのライフサイクルの一部である場合、プロジェクトはビルドされるたびにクリーンアップされます。これは明らかに望ましくないため、クリーンアップには独自のライフサイクルが与えられています。

mvn install標準ライフサイクルにより、プロジェクトに不慣れなユーザーは、単一のコマンドを発行するだけで、すべてのMavenプロジェクトを正確にビルド、テスト、インストールできるようになります。デフォルトでは、MavenはPOMファイルを生成されたJARファイルとWARファイルにパッケージ化します。diet4j ^[13]などのツールは、この情報を使用して、すべてのプロジェクトコードを含む「uber」jarを必要とせずに、実行時にMavenモジュールを再帰的に解決して実行できます。

Maven の中心的な機能は依存関係の管理です。Maven の依存関係処理メカニズムは、ソフトウェア ライブラリやモジュールなどの個々の成果物を識別する座標系を中心に構成されています。上記の POM の例では、プロジェクトの直接の依存関係として JUnit 座標を参照しています。たとえば、Hibernateライブラリを必要とするプロジェクトでは、POM で Hibernate のプロジェクト座標を宣言するだけで済みます。Maven は依存関係と Hibernate 自体に必要な依存関係 (推移的依存関係と呼ばれる) を自動的にダウンロードし、ユーザーのローカル リポジトリに保存します。デフォルトでは、ライブラリの検索に Maven 2 Central Repository ^[2]が使用されますが、POM 内で使用するリポジトリ (たとえば、会社のプライベート リポジトリ) を構成することもできます。

Maven と Ant の根本的な違いは、Maven の設計では、すべてのプロジェクトが特定の構造と、サポートされている一連のタスク ワークフロー (ソース管理からのリソースの取得、プロジェクトのコンパイル、ユニット テストなど) を持つとみなされることです。ほとんどのソフトウェア プロジェクトは、事実上これらの操作をサポートし、実際に明確に定義された構造を持っていますが、Maven では、この構造と操作の実装の詳細を POM ファイルで定義する必要があります。したがって、Maven は、プロジェクトの定義方法に関する規則と、すべてのプロジェクトで一般的にサポートされているワークフローのリストに依存しています。^[14]

^{中央リポジトリ検索エンジン[15]}などの検索エンジンがあり、これを使用してさまざまなオープンソースライブラリやフレームワークの座標を見つけることができます。

1 台のマシンで開発されたプロジェクトは、ローカル リポジトリを通じて相互に依存できます。ローカル リポジトリは、ダウンロードされた依存関係のキャッシュとして、またローカルで構築された成果物の集中的な保存場所として機能したシンプルなフォルダー構造です。Maven コマンドはmvn installプロジェクトをビルドし、そのバイナリをローカル リポジトリに配置します。その後、他のプロジェクトは、POM でその座標を指定してこのプロジェクトを利用できます。

Java プログラミング言語をターゲットとするいくつかの一般的な統合開発環境 (IDE)のアドオンは、Maven と IDE のビルド メカニズムおよびソース編集ツールの統合を提供し、Maven が IDE 内からプロジェクトをコンパイルできるようにし、コード補完のクラスパスを設定したり、コンパイラ エラーを強調表示したりできるようにします。

Maven を使用した開発をサポートする一般的な IDE の例は次のとおりです。

• 日食
• ネットビーンズ
• IntelliJ IDEA
• Jビルダー
• JDeveloper (バージョン 11.1.2)
• マイエクリプス
• ビジュアルスタジオコード

これらのアドオンは、POM を編集したり、POM を使用してプロジェクトの依存関係の完全なセットを IDE 内で直接決定したりする機能も提供します。

IDE がコンパイルを実行しなくなった場合、IDE に組み込まれている機能の一部は失われます。たとえば、Eclipse の JDT には、編集された単一の Java ソース ファイルを再コンパイルする機能があります。多くの IDE は、Maven が推奨するフォルダーの階層ではなく、フラットなプロジェクト セットで動作します。このため、 Maven を使用する場合、IDE でのSCMシステムの使用が複雑になります。^{[16] [17] [18]}

• Apache Continuum (廃止)
• アパッチゼリー
• ハドソン （廃盤）
• ジェンキンス
• ビルド自動化ソフトウェアのリスト
• ソナタイプ ネクサス

• O'Brien, Tim; et al. 「Maven: The Complete Reference」。Sonatype.com。Sonatype。2013年3月15 日閲覧。
• Maven: 決定版ガイド。ソナタイプ社。オライリー・メディア社、2009 年。p. 470.ISBN​ 9780596551780. 2013年4月17日閲覧。{{cite book}}: CS1 メンテナンス: その他 (リンク)
• Van Zyl, Jason (2008-10-01)、Maven: Definitive Guide (初版)、O'Reilly Media、pp. 468、ISBN 978-0-596-51733-5
• 「Maven2 から JUnit テストを実行する」。JUnit in Action (第 2 版)。Manning Publications。2011年。152 ～ 168 ページ。ISBN 978-1-935182-02-3。
• Maven ビルドのカスタマイズ. Packt. 2013. pp. 1–250. ISBN 9781783987221。
• Apache Maven 3 をマスターする。 2014.p. 298.ISBN​ 9781783983865。

• 公式サイト