19

私はついに、自分のプロジェクトで使用済みの宣言されていない依存関係または未使用の宣言された依存関係を持たないことに慣れました。依存関係にリストされている未使用の宣言されたランタイム/テスト依存関係を追跡することは非常に困難ですが:分析します... pom.xml にコメントを書き込むか、テストまたはランタイムに必要であることを知るためにそれらを管理する必要があります。

しかし、バージョンの競合を解決する方法はまだ不明です。推移的な依存関係について。

ニアレストウィン戦略はどのように正確に機能しますか? あるバージョンが別のバージョンで使用されるのはいつですか?

  • バージョン番号を使用して宣言されていない依存関係を宣言すると、常に勝ちます

  • 依存関係のバージョンを明示的に指定しない場合、Maven はこの依存関係に関して発生する可能性のあるバージョンの競合を解決できません (奇妙ですが、ここに書かれています) 。

  • 宣言されていない使用済み依存関係を宣言しない場合、最も近いレベルから推移的な依存関係が選択され (最も近い勝利戦略)、競合が同じレベルにある場合は、何らかの形でバージョン A とバージョン B の間で決定されます ... おそらく最初の依存関係を処理するときに来るもの

4

2 に答える 2

2

依存関係の解決は、あなたが説明したのとまったく同じように機能すると思います。

<scope>また、子タグを使用すると、生活がずっと楽になると思います<dependency>

Mavenの公式Webサイトからの引用：

  1. compile: これはデフォルトのスコープで、何も指定されていない場合に使用されます。コンパイルの依存関係は、プロジェクトのすべてのクラスパスで利用できます。さらに、それらの依存関係は依存プロジェクトに伝播されます。
  2. provided: これは compile によく似ていますが、実行時に JDK またはコンテナーが依存関係を提供することを期待していることを示します。たとえば、Java Enterprise Edition 用の Web アプリケーションを構築する場合、サーブレット API および関連する Java EE API への依存関係を提供範囲に設定します。これは、Web コンテナーがこれらのクラスを提供するためです。このスコープは、コンパイルおよびテスト クラスパスでのみ使用でき、推移的ではありません。
  3. runtime このスコープは、依存関係がコンパイルには必要ないが、実行には必要であることを示します。これはランタイムおよびテスト クラスパスにありますが、コンパイル クラスパスにはありません。
  4. test: このスコープは、依存関係がアプリケーションの通常の使用には必要なく、テストのコンパイルおよび実行フェーズでのみ使用できることを示します。
  5. system: このスコープは、それを含む JAR を明示的に提供する必要があることを除いて、provided と似ています。アーティファクトは常に利用可能で、リポジトリで検索されません。
  6. import: (Maven 2.0.9 以降でのみ使用可能) このスコープは、セクション内のタイプ pom の依存関係でのみ使用されます。これは、指定された POM をその POM のセクションの依存関係に置き換える必要があることを示します。それらは置き換えられるため、インポートのスコープを持つ依存関係は、依存関係の推移性の制限に実際には関与しません。
于 2011-12-28T14:17:50.570 に答える
1

依存関係管理のドキュメントへのリンクがいくつかあります。

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html (セクション「依存範囲」のインポートテーブル)

依存関係の解決を説明するドイツのジャーナルに神の記事があります-記事のbibtex参照は次のとおりです。

http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.htmlの sonatype book に依存関係プラグインに関するセクションがあり ます。

お役に立てば幸いです。

于 2012-01-12T22:15:10.397 に答える