Maven 3座標と依存

座標
Mavenの座標はただ一つの項目がMaven倉庫にある位置を示すために用いられます。Mavenの座標は主にgroupId、artiftId、version、packaging、classiierの5つの要素からなります。groupId、artiftId、versionは必要な元素です。packaging、classiferは省略できます。

groupId：現在のプロジェクトに属するパッケージを定義し、Maven倉庫のディレクトリ構造

に対応している。

アーティファクトId：通常は現在のプロジェクト名で、プロジェクト名ディレクトリ名

に対応しています。

version：プロジェクトのバージョンは、バージョンディレクトリ名

に対応しています。

packaging：包装の方式を指定して、デフォルトはjarカバンで、オプション(war、maven-plugin、pom、zipなど)

classifer：出力の構築を定義するためのいくつかの付属の構築を支援するために、直接定義することはできません。一般的にプラグインがあり、

を生成するのに役立ちます。
座標を使用して、maven倉庫に依存ファイルを探す場合、以下の経路で検索します。
$RESPORTY_HOME/groupId(replace.to/)/artiftId/version/artiftId-version[-classier].packaging(packagingがmaven-pluginの場合は拡張子もjar)
versionがSNAPSHOPバージョンであるとき、リモート倉庫にリリースされます。SNAPSHOPは当時のタイムスタンプに置き換えられます。依存されているときにタイムスタンプのバージョンが一番近いです。
依存
Mavenのpomファイルでの配置依存性には、以下のような要素が含まれています。

<dependency>
  <groupId></groupId>
  <artifactId></artifactId>
  <version></version>
  <type></type>
  <scope></scope>
  <optional></optional>
  <exclusions>
    <exclusion></exclusion>
  </exclusions>
</dependency>

groupId、artiftId、versionは、1つの構築

を一意に表すために使用される。

type：依存するタイプで、プロジェクト座標の定義に対応したpackagingは、デフォルトはjar

です。

scope：依存の範囲で、オプション値はcomple、test、provided、runtime、system、import

があります。

optional：オプションの依存性を示すかどうかは、デフォルトはfalse

です。

exclusions：伝達性依存性を排除するための

依存の範囲

comppile：コンパイル範囲の依存性、デフォルトのオプションは、コンパイル、テスト、実行の3つの段階に依存する必要があります

test：テスト範囲依存性は、junnit

のようなテスト段階でのみ使用される依存性です。

provided：コンパイルとテスト段階にはこの依存性が必要です。運行期間が必要ではない時、よくあるservlet-apiのように、運行期間容器は

を提供します。

runtime：運転時の範囲依存性は、JDBC駆動の実現のように、JDKが提供するJDBCインターフェース

だけがコンパイルされています。

system：システム範囲依存性は、providedに依存する方位と同じであり、systemを使用して表示しなければならないのは、system Pathを使用して依存ファイルパス

を指定するだけである。

import：この依存範囲は特殊で、コンパイル、テスト、実行の三つの段階に影響しません。あるpomファイルに配置されたdependencyManagementの構成内容を多重化するためのものです。このscopeを使うdependencyはいくつかの条件を満たすために有効でなければなりません。
            (1)dependencyManagement要素内でなければならない
            （2）packgingは必ずpomであること。
依存の伝達
       現在のプロジェクトの直接依存性は他のjarにも依存しているかもしれません。この依存性は二級依存といいます。Mavenは依存の伝達メカニズムを使って二級以上の依存をうまく処理してくれます。
        project->spring-core->comons-loging
        現在のプロジェクトはspring-coreに依存していますが、spring-coreはまたcomons-logingに依存しています。プロジェクトのpomファイルに表示される申明commons-logingの依存は必要ありません。Mavenはspring-coreのpomファイルを通して最終的にcommon-gingの依存をproject項目にロードしますが、依存しています。
一級依存\二級依存
comple
test
プロヴィッド
runtime
comple
comple
——
——
runtime
test
test
——
——
test
プロヴィッド
プロヴィッド
——
プロヴィッド
プロヴィッド
runtime
runtime
——
——
runtime
簡単に言えば

において、二級の依存範囲がcompleである場合、伝達依存後の方位と一級の依存度は同じである。

において、二級依存の範囲がtestである場合、この依存は伝達されない。

、二級の依存範囲がprovidedである場合、一級の依存だけがプロvidedに伝達されます。

において、第2レベルの依存範囲がruntimeである場合には、1レベルの依存度を除いて、runtime範囲が伝達され、残りの範囲は1レベルの依存度と一致する

である。
依託調停
    プロジェクトの間接依存性が同じプロジェクトの異なるバージョンがある場合、Mavenは同じプロジェクトを何度もロードすることができません。
    A->B->C（1.0）、A->D->C（2.0）、A->E->F->C（3.0）
    AはBとDとEに依存していますが、BはCの1.0バージョンに依存しています。DはCの2.0バージョンに依存しています。FはCの3.0バージョンに依存しています。Aに3つのバージョンのCをロードすることはできません。これは明らかに間違っています。したがって、Mavenはこのような場合、どのバージョンをロードするかを決定する規則を制定しました。

は、まず依存する深さで選択し、浅い優先度であるため、C（3.0）が

をロードすることは不可能である。

は、同じ深さの場合、pomファイルにおいて最初に解析された優先

である。
オプションの依存
    上記のpomファイルでは、依存性を宣言する時にtrueを使用して、この依存はオプションの依存として宣言されています。オプションの依存は伝達されません。
    A->B，B->C(オプション)、B->D(オプション)
    上のCとDは渡されないと思います。Aのpomで明確な声明はCを使うかDを使うか、イメージの例を挙げてください。Bは永続的に分離されたツールバッグです。いろいろなデータベースをサポートしています。C、DはMysqlの接続バッグ、Oracleの接続バッグと見なしてもいいです。C、DはBのpomでの依存声明はオプションです。彼らはAに渡されません。Aでは実際に使用するデータベースに基づいて、使用する接続パッケージを宣言する必要があります。