スコープが「インポート」の場合と「インポート」のない場合の「pom」タイプの依存関係の違いは何ですか?


112

Maven 2.0.9以降では、

<type>pom</type>
<scope>import</scope>

<dependencyManagement>セクション。

私が理解しているように、このpomに含まれている依存関係は、元々ここで定義されているかのように「置き換え」られます。

上記のソリューションとimportスコープのないこのpomへの単純な依存関係の違いは何ですか(後者は「依存関係のグループ化」と呼ばれているのを見ました)。依存関係の優先順位を解決する間、そのような「グループ化された」依存関係の優先順位が低くなる唯一の違いはありますか?

回答:


187

管理された依存関係のみをインポートできます。つまり、他のPOMはプロジェクトのPOMのセクションにのみインポートできdependencyManagementます。すなわち

...
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>other.pom.group.id</groupId>
            <artifactId>other-pom-artifact-id</artifactId>
            <version>SNAPSHOT</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>   
    </dependencies>
</dependencyManagement>
...

その後、のdependencyManagementセクションで定義されているすべての依存関係other-pom-artifact-idがPOMのdependencyManagementセクションに含まれます。その後dependency、POM(およびそのすべての子POM)のセクションでこれらの依存関係を参照できますversion

ただし、POMで通常の依存関係を定義するだけの場合、のセクションからのother-pom-artifact-idすべてがプロジェクトに推移的に含まれますが、のセクションで定義された依存関係はまったく含まれません。dependenciesdependencyother-pom-artifact-iddependencyManagementother-pom-artifact-id

したがって、基本的には2つの異なるメカニズムが2つの異なるタイプの依存関係(管理された依存関係と通常の依存関係)のインポート/インクルードに使用されます。

MavenのWebサイトには、私よりもはるかによく説明できる良いページがあります。Mavenの依存関係管理と依存関係のインポートに関する特定の情報も含まれています。


1
pomAがpomBの親である場合、プロジェクトAの依存関係管理にスコープを指定してBを配置できますimportか?
Janez Kuhar

それがどのように機能するかを説明するための素晴らしい答えですが、なぜですか?他の依存関係を推移的に含めたくないのはなぜですか?また、両方を行うことができますか?other-pom-artifact-idをインポートしてから、other-pom-artifact-idも依存関係として宣言しますか?
Junchen Liu 2016

DZoneに関する1つの記事は別のことを述べています:... <dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>pomlib-lib</artifactId> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>${project.groupId}</groupId> <artifactId>pomlib-war</artifactId> <type>war</type> </dependency> </dependencies> </project>DRYとSkinny War
coz

1
@JunchenLiu:プロジェクトAのいくつかの機能のみを使用しているとしましょう。その機能に必要な推移的な依存関係のみを含めるように選択できます。<dependency>で<exclude>を使用することによっても解決できます。たとえば、これをチェックアウトします:jdbi.org
#_

15

pomタイププロジェクトをsimple dependency別のプロジェクトとしてにすることはできません。(まあ、あなたはできます-しかしそれは有用なことを何もしません)。parent-child関係があるだけです。これは本質的にmanaging dependency through inheritanceです。

importセクションのpom型依存関係のスコープを<dependencyManagement>使用すると、同等のmultiple inheritance

あなたは違うかもしれない poms -それぞれmanagingが関連する依存関係の束。これらを使用するプロジェクトができimport、これらのpoms、その後、彼らはバージョンを心配することなく、必要があるとの依存関係を指定します。これは基本的にはbill of materials概念であり、@ DB5によって指定されたリンクに示されています。

これはparent poms、複雑なマルチモジュールプロジェクトが大きくなりすぎて扱いにくくなるのを防ぐのに役立ちます。


8
本気ですか?通常のpom(独自の依存関係を持つ)を他のプロジェクト(パッケージングwar)の通常の依存関係として配置し、ターゲットプロジェクトのWEB-INF / libに含まれるpomプロジェクトからすべての依存関係を取得しました。私はこの質問を:)求めている理由です
grafthez

2
@Raghuramに感謝します。質問に答えるときに、親POMオプションについて言及するのを完全に忘れていました。pomタイプのプロジェクトを単純な依存関係として持つことは可能です。元の質問で述べたように、依存関係
DB5


5

オブジェクト指向プログラミングのパラダイムと非常によく似た2つの概念が、質問への回答に役立ちます。

  1. dependencyManagementのいずれかで、目的は、他のプロジェクトで詳細及び再利用の管理である相続(経由-セクションでは、現在のプロジェクトだけで依存関係とその詳細を宣言する)またはインポート(スコープ)。これは、プログラムでデータ型を宣言して使用できるようにすることと似ています。

  2. 依存セクションは、必要に応じて下に宣言された依存関係の詳細(すなわち、バージョンなど)を継承し、プロジェクト内の依存関係の実際の使用を定義dependencyManagment。これが、それらをdependencyManagmentに配置するだけの場合、依存関係が欠落する理由です。これは、必要なプログラムでデータ型の変数インスタンスをインスタンス化することに似ています。


これは良いことですが、上記とは別の質問に答えます。:-)
Rick-777
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.