dependencyManagementと
dependenciesの違いは何ですか? Apache Maven の Web サイトでドキュメントを見ました。 dependencyManagement
で定義された依存関係は、バージョンを指定することなくその子モジュールで使用することができるようです。
例えば、こんな感じです。
親プロジェクト(Pro-par)は dependencyManagement
の下で依存関係を定義する。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8</version>
</dependency>
</dependencies>
</dependencyManagement>
それから、プロパーの子では、junitを使うことができます。
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
しかし、junitを親pomで定義する必要があるのだろうか?必要なモジュールで直接定義すればいいのでは?
私はこの質問に流行遅れですが、受け入れられたものよりも明確な応答の価値があると思います(これは正しいですが、自分で推測する必要がある実際の重要な部分を強調していません)。
親POMでは、 < dependencies>
と< dependencyManagement>
の主な違いは次のとおりです。
< dependencies>
セクションで指定されたアーティファクトは、常に子モジュールの依存関係として含まれます。
< dependencyManagement>
セクションで指定されたアーティファクトは、子モジュール自体の< dependencies>
セクションでも指定されている場合にのみ子モジュールに含まれます。 なぜいいのですか? 親のバージョンやスコープを指定し、子POMの依存関係を指定するときにそれらを除外できるためです。これは、各子モジュールのバージョンを指定せずに、子モジュールの依存関係に統一バージョンを使用するのに役立ちます。
Mavenサイトのドキュメントは恐ろしいです。 dependencyManagementが行うことは、依存関係の定義(バージョン、除外など)を親のpomに移動するだけであり、子pomsにgroupIdとartifactIdを配置するだけです。 それだけです(親ポンチェーンなどを除いて、それもそれほど複雑ではありません-依存関係管理は親レベルでの依存関係に勝ちます-しかし、それについて質問がある場合、またはインポートする場合は、Mavenのドキュメントが少し優れています)。
Mavenサイトの「a」、「b」、「c」のゴミをすべて読んで混乱した後、私は彼らの例を書き直しました。 したがって、共通の依存関係(betaShared)を共有する2つのプロジェクト(proj1とproj2)がある場合、その依存関係を親pomに移動できます。 その間、他の依存関係(アルファとチャーリー)を上に移動することもできますが、それがプロジェクトにとって理にかなっている場合に限られます。 したがって、前の文で概説した状況については、親pomでのdependencyManagementを使用した解決策を次に示します。
<。!-言語:xml -->。
<!-- ParentProj pom -->
<project>
<dependencyManagement>
<dependencies>
<dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
<groupId>alpha</groupId>
<artifactId>alpha</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>zebra</groupId>
<artifactId>zebra</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
<artifactId>charlie</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
<dependency> <!-- defining betaShared here makes a lot of sense -->
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
<!-- Child Proj1 pom -->
<project>
<dependencies>
<dependency>
<groupId>alpha</groupId>
<artifactId>alpha</artifactId> <!-- jar type IS DEFAULT, so no need to specify in child projects -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>
<!-- Child Proj2 -->
<project>
<dependencies>
<dependency>
<groupId>charlie</groupId>
<artifactId>charlie</artifactId>
<type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>
私の意見では、十分に強調されていないことが1つあります。それは不要な継承です。
増分例は次のとおりです。
私は私の「親」のポンポンで宣言します:
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
</dependencies>
ブーム。! Child A
、 Child B
、 Child C
モジュールに持っています。
-子供のポンポンに受け継がれた無罪。 -管理する単一の場所。 -子供用ポンプで何かを再宣言する必要はありません。 -必要に応じて、「チャイルドB」で「バージョン18.0」に再デールしてオーバーライドできます。
しかし、「チャイルドC」でグアバを必要とせず、将来の「チャイルドD」モジュールと「チャイルドE」モジュールのどちらにもない場合はどうでしょう?
彼らはまだそれを継承し、これは望ましくありません。!。 これは、Java God Objectコードの ⁇ いと同じです。クラスからいくつかの便利なビットと、不要なものも大量に継承します。
ここで、 < dependencyManagement>
が機能します。 これを親pomに追加すると、すべての子モジュールが表示を停止します。 したがって、強制して、それを必要とする個々のモジュールに入り、再度宣言します(ただし、バージョンなしで「子A」と「子B」)。
そして、明らかに、「チャイルドC」では実行しないため、モジュールは無駄のないままです。
< depedencies>
と < dependencyManagement>
タグとmavenの違いを概説するいくつかの回答があります。
ただし、簡潔に以下に詳述するいくつかのポイント:
1。 < dependencyManagement>
は、さまざまなモジュールで使用されるすべての依存関係(子ポンレベルで使用)を統合することを可能にします- clarity 、 central dependency version management 。
2。 < dependencyManagement>
は、必要に応じて依存関係を簡単にアップグレード/ダウングレードできるようにします。他のシナリオでは、これはすべての子供ポンレベルで行使する必要があります-一貫性。
3。 < dependencies>
タグで提供される依存関係は常にインポートされますが、親pomの< dependencyManagement>
で提供される依存関係は、子pomが < dependencies>
タグにそれぞれのエントリを持っている場合にのみインポートされます。
申し訳ありませんが、パーティーに遅れました。
mvn dependency:tree
コマンドを使用して違いを説明してみましょう。
以下の例を検討してください。
親POM-私のプロジェクト。
<modules>
<module>app</module>
<module>data</module>
</modules>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>
</dependencies>
</dependencyManagement>
子POM-データモジュール。
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
</dependency>
</dependencies>
子POM-アプリモジュール(追加の依存関係がないため、依存関係を空のままにします)。
<dependencies>
</dependencies>
mvn dependency:tree
コマンドを実行すると、次の結果が得られます。
Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:
MyProject
app
data
------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) @ MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile
------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) @ app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile
------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) @ data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile
Googleグアバはすべてのモジュール(親を含む)で依存関係としてリストされていますが、アパッチコモンズはデータモジュールでのみ依存関係としてリストされています(親モジュールでもリストされていません)。
親POMでは、 < dependencies>
と< dependencyManagement>
の主な違いは次のとおりです。
< dependencies>
セクションで指定されたアーティファクトは、常に子モジュールの依存関係として含まれます。
2つの違いは、Maven Webサイトのドキュメントで利用可能な依存関係管理要素の必要かつ十分な定義と思われるものに最もよくもたらされます。
依存関係管理。
「これから継承するプロジェクトのデフォルト依存情報。 このセクションの依存関係はすぐには解決されません。 代わりに、この1つから派生したPOMが、一致するgroupIdとartifactIdによって記述された依存関係を宣言する場合、このセクションのバージョンと他の値は、まだ指定されていない場合にその依存関係に使用されます。"。 [https://maven.apache.org/ref/3.6.1/maven-model/maven.html]。
別のページで入手できるいくつかの詳細情報とともに読む必要があります。
"。依存関係参照と依存関係管理セクションを照合するための最小限の情報セットは、実際には{groupId、artifactId、type、classifier}です。 多くの場合、これらの依存関係は、分類子のないjarアーティファクトを指します。 これにより、タイプフィールドのデフォルトはjarであり、デフォルトの分類子はnullであるため、IDセットを{groupId、artifactId}に省略できます。” [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]。
したがって、すべてのサブ要素(スコープ、除外など).、)依存要素(groupId、artifactId、type、classifier以外、バージョンだけではない)の、dempencyElement内の依存関係を指定するポイントで(したがって、そこから継承される)ロックダウン/デフォルトに使用できます。 タイプと分類子のサブ要素に依存を指定した場合。 (すべてのサブ要素を確認するには、最初に引用したWebページを参照してください。) それぞれjarではなくnullではありません。, あなたが必要とするでしょう。 {groupId。, artifactId。, 分類子。, タイプ。} 参照する。 (解決する。) 依存関係管理要素に由来する継承の任意の時点での依存関係。 それ以外の場合は、分類子とタイプ(それぞれjarとnull)のデフォルトをオーバーライドしない場合は、{groupId、artifactId}で十分です。 したがって、デフォルトはその定義の良いキーワードです。依存関係を参照するポイントで明示的に割り当てられた値(もちろん、groupId、artifactId、classifier、type以外)は、dempencyManagement要素のデフォルトをオーバーライドします。
したがって、依存関係管理要素以外の依存関係要素は、依存関係管理要素への参照として、またはスタンドアロンとして、すぐに解決されます(つまり、. ローカルリポジトリにインストールされ、クラスパスで利用可能)。