目次
1.Mavenとは
Maven は Apache のオープン ソース プロジェクトであり、Java プロジェクトを管理および構築するためのツールです。
公式ウェブサイト: Maven – Apache Maven へようこそ
https://maven.apache.org/ 1999 年 7 月に設立された Apache Software Foundation は、現在、世界最大かつ最も人気のあるオープン ソース ソフトウェア財団であり、専用のサポートも提供しています。 -オープンソース プロジェクトから生まれた営利団体。
2. Maven の役割
Maven で何ができますか?
依存関係管理
統一されたプロジェクト構造
プロジェクトのビルド
依存関係の管理:
プロジェクトの依存関係 (jar パッケージ) の管理に maven を使用する場合、この問題を解決するのに非常に便利です。Maven プロジェクトの pom.xml ファイルに、下の図に示すように構成を追加するだけです。
統一されたプロジェクト構造:
Maven プロジェクトを作成すると、統一された標準のプロジェクト ディレクトリ構造を自動的に生成するのに役立ちます。
プロジェクトのビルド:
Maven は、標準のクロスプラットフォーム (Linux、Windows、MacOS) の自動化されたプロジェクト構築方法を提供します
3.Mavenの概要
3.1 Mavenの紹介
Apache Maven は、Project Object Model (Project Object Model、POM と呼ばれる) の概念に基づいたプロジェクト管理および構築ツールであり、小さな記述を通じてプロジェクトの構築、レポート、および文書化を管理します。情報。
Maven の役割:
便利な依存関係管理
統一されたプロジェクト構造
標準的なプロジェクトのビルド プロセス
3.2 Maven モデル
プロジェクト オブジェクト モデル
依存関係管理モデル (依存関係)
ビルドのライフサイクルとフェーズ
ビルドのライフサイクルとフェーズ
上図の紫色で囲んだ部分が標準施工工程の完成です。コンパイルする必要がある場合、Maven は使用するコンパイル プラグインを提供し、パッケージ化する必要がある場合、Maven は使用するパッケージング プラグインを提供します。
プロジェクト オブジェクト モデル
上図の紫色で囲んだ部分がプロジェクト オブジェクト モデルに属し、独自のプロジェクトを独自の座標を持つオブジェクト モデルに抽象化します。
依存関係管理モデル (依存関係)
上の図の紫色で囲まれた部分は依存関係管理モデルに属し、座標を使用して、現在のプロジェクトが依存しているサードパーティの jar パッケージを記述します。
以前はプロジェクトで jar パッケージが必要だったときに、jar パッケージをプロジェクトの下の lib ディレクトリに直接コピーしましたが、pom.xml ファイルに記述された座標で目的の jar パッケージ ファイルを見つけるにはどうすればよいでしょうか。
回答: Maven リポジトリ
3.3 Maven リポジトリ
倉庫: リソースを保管し、さまざまな jar パッケージを管理するために使用されます
ウェアハウスの本質は、すべての依存関係 (つまり、jar パッケージ) と開発中のプラグインを格納するために使用されるディレクトリ (フォルダー) です。
Maven ウェアハウスは次のように分割されています。
ローカル ウェアハウス: 自分のコンピューター上のディレクトリ (jar パッケージの保存に使用)
中央倉庫: Maven チームによって管理されている世界で唯一の倉庫。倉庫住所:中央リポジトリ:
リモート倉庫 (プライベート サーバー): 通常、会社のチームによって構築されたプライベート倉庫
対応する依存 jar パッケージをインポートするためにプロジェクトで座標が使用される場合、ローカル ウェアハウスに対応する jar パッケージがあるかどうかが最初にチェックされます。
存在する場合は、プロジェクトで直接参照されます
そうでない場合は、中央倉庫に移動して、対応する jar パッケージをローカル倉庫にダウンロードします。
リモート倉庫（プライベートサーバー）も構築できれば、今後のjarパッケージの検索順序は、ローカル倉庫→リモート倉庫→中央倉庫となります。
4. 依存関係の管理
4.1 依存関係の設定
依存関係: 現在のプロジェクトの実行に必要な jar パッケージを参照します。複数の依存関係をプロジェクトに導入できます。
例: 現在のプロジェクトでは、logback を使用してログを記録する必要がありますが、この時点で、maven プロジェクトの pom.xml ファイルに logback の依存関係を導入できます。具体的な手順は次のとおりです。
<dependencies> タグを pom.xml に記述します。
<dependencies> タグで <dependency> を使用して座標を導入します
groupId、artifactId、座標のバージョンを定義します
<dependencies> <!-- 第1个依赖 : logback --> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.11</version> </dependency> <!-- 第2个依赖 : junit --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> </dependencies>更新ボタンをクリックして、新しく追加された座標をインポートします
依存関係の更新: 新しい依存関係が導入されるか、既存の依存関係の構成が変更されるたびに、最新の座標を追加できるようにします。予防：
インポートされた依存関係がローカル倉庫に存在しない場合は、リモートの倉庫/中央倉庫に接続し、依存関係をダウンロードします (このプロセスには時間がかかります。しばらくお待ちください)。
従属座標情報がわからない場合は、 mvn の中央倉庫 ( https://mvnrepository.com/ )で検索できます。
依存関係を追加するいくつかの方法:
中央リポジトリ検索に依存座標を活用
IDEA ツールを使用して依存関係を検索する
Maven に慣れたら、依存関係をすばやくインポートします
4.2 依存関係の配信
4.2.1 依存性は推移的
初期の頃に maven を使用していなかったとき、依存する jar パッケージをプロジェクトに追加するには、すべての jar パッケージをプロジェクト プロジェクトにコピーする必要がありました。以下の図に示すように、logback-classic が必要な場合、logback-classic は logback-core と slf4j に依存しているため、3 つの jar パッケージすべてをプロジェクト project にコピーする必要があります。
現在はmavenを使用しており、プロジェクトでlogback-classicを使用する必要がある場合は、pom.xml構成ファイルにlogback-classicの依存座標を追加するだけです。
pom.xml ファイルには logback-classic 依存関係のみが追加されていますが、maven の依存関係は推移的であるため、他の依存 jar パッケージが自動的にインポートされます。
依存関係の転送は、次のように分類できます。
直接的な依存関係: 現在のプロジェクトの依存関係の構成を通じて確立された依存関係
間接的な依存関係: 依存リソースが他のリソースに依存している場合、現在のプロジェクトは他のリソースに間接的に依存しています
projectA は projectB に依存します。projectA の場合、projectB は直接の依存関係です。
また、projectB は projectC と他の jar パッケージに依存しています。このとき、projectC の依存関係も projectA に引き継がれます。projectA の場合、projectC は間接的な依存関係です。
4.2.2 依存関係の除外
質問: 以前、依存関係は推移的であると述べました。その場合、A は B に依存し、B は C に依存します。A が C に依存したくない場合は、依存できますか?
回答: Maven プロジェクトでは、依存関係を除外することでこれを行うことができます。
除外依存関係とは何ですか?
依存関係を除外する: 依存リソースをアクティブに切断することを指します。(除外されたリソースはバージョンを指定する必要はありません)
<dependency> <groupId>com.itheima</groupId> <artifactId>maven-projectB</artifactId> <version>1.0-SNAPSHOT</version> <!--排除依赖, 主动断开依赖的资源--> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> </exclusions> </dependency>
4.3 依存範囲
依存する jar パッケージをプロジェクトにインポートすると、デフォルトでどこでも使用できます。
依存関係の使用範囲を制限したい場合は、 <scope> タグを使用してその範囲を設定できます。
行動範囲:
メインプログラムのスコープが有効（メインフォルダのスコープ内）
テストプログラムのスコープが有効（テストフォルダのスコープ内）
パッケージ運用への参加の有無（パッケージ指導の範囲内）
scope タグを使用して、junit 依存関係の依存関係のスコープを指定します。この依存関係はテスト環境でのみ使用でき、他の環境では使用できません。
scope タグの値の範囲:
4.4 ライフサイクル
4.4.1 はじめに
Maven のライフサイクルは、すべての構築プロセスを抽象化して統合することです。プロジェクトの構築を説明し、それが通過するステージを示します。
Maven が登場する前から、プロジェクト構築のライフサイクルはすでに存在しており、ソフトウェア開発者は毎日、プロジェクトのクリーニング、コンパイル、テスト、デプロイを行っていました。誰もがノンストップで建設作業を行っていますが、企業や企業、プロジェクトやプロジェクトは、同じような作業を行うために異なる方法を使用することがよくあります。
Maven は、多数のプロジェクトおよび構築ツールから学習および反映し、高度に完全で拡張しやすい一連のプロジェクト構築ライフサイクルを要約します。このライフ サイクルには、プロジェクトのクリーンアップ、初期化、コンパイル、テスト、パッケージ化、統合テスト、検証、展開、サイト生成、およびほとんどすべての構築手順が含まれます。
Maven は、プロジェクト構築のライフサイクルを 3 つのセット (互いに独立) に分割します。
clean: 作業をクリーンアップします。
デフォルト: コア ジョブ。例: コンパイル、テスト、パッケージング、インストール、展開など。
site: レポートの生成、サイトの公開など。
これらの 3 つのライフ サイクル セットを見てきましたが、それらには非常に多くの段階があり、非常に多くのライフ サイクル段階があります。
• clean: 以前のビルドで生成されたファイルを削除します
• compile: プロジェクトのソース コードをコンパイルします。
• テスト: 適切な単体テスト フレームワーク (junit) を使用してテストを実行します。
• package: jar、war などのコンパイル済みファイルをパッケージ化します。
• install: プロジェクトをローカル リポジトリにインストールします。
Maven のライフサイクルは抽象的です。つまり、ライフサイクル自体は実際の作業を行いません。Maven の設計では、実際のタスク (ソース コードのコンパイルなど) はプラグインによって実行されます。
プログラマーが Maven ライフサイクルを使いやすくするために、IDEA ツールは右側の Maven ツールバーにクイック アクセス チャネルを提供しています。
ライフ サイクルの順序は、クリーン --> 検証 --> コンパイル --> テスト --> パッケージ --> 検証 --> インストール --> サイト --> デプロイです。
焦点を当てる必要があるのは、クリーン --> コンパイル --> テスト --> パッケージ --> インストールです。
説明: 同じライフサイクルで、後のライフサイクルを実行すると、前のライフサイクルが実行されます。
考えてみてください: パッケージのライフ サイクルが実行されている場合、クリーン ライフ サイクルとコンパイル ライフ サイクルは実行されますか?
clean は実行されず、コンパイルは実行されます。コンパイルとパッケージは同じライフサイクルに属していますが、クリーンとパッケージは同じライフサイクルに属していないためです。
4.4.2 実行
日常の開発において、指定されたライフサイクルを実行したい場合、2 つの実行方法があります。
アイデア ツールの右側にある Maven ツールバーで、対応するライフ サイクルを選択し、ダブルクリックして実行します。
DOS コマンド ラインで、maven コマンドを実行します。
方法 1: アイデアでライフサイクルを実行する
方法 2: コマンド ラインでライフサイクルを実行する