あなたが発見したように、バージョン範囲は悪です。
本当の問題は、バージョン範囲が人々を誘惑して良いアイデアだと思わせるサイレンであるということです。
バージョン範囲は、開発者が一連のバージョンから必要なバージョンを選択できるようにするためのヒントと見なす必要があります。
Maven の間違いは、バージョン範囲をpom.xml
含むアーティファクトを公開できるようにするために、そもそもバージョン範囲を 内で定義できるようにしたことです。
バージョン範囲を使用する推移的な依存関係を持つアーティファクトに依存すると、ビルドの問題を解決する方法は実際には 2 つしかありません (1 つは 2 番目のより洗練されたバージョンです)。
推移的な依存関係に独自の依存関係を追加しますが、範囲の代わりに固定されたバージョンを使用します...例
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.1.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.1.2.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<optional>true</optional>
依存関係は推移的ではないため、依存関係をリストする必要はありません。<scope>provided</scope>
同様に、同じ理由で依存関係をリストする必要もありません。
上記と同様ですが、最初に依存関係に除外を追加することでより安全になります。
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.1.0.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.1.2.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
この 2 つのうち、私は後者を好みます。なぜなら、これらの依存関係が明示的に言及されている理由について、少なくとも人々にヒントを与えるからです。
したがって、元の質問に戻るには、要点は、pom.xml
.
spring-data-jpa:1.1.1.RELEASE
座標が異なる完全に異なる推移的な依存関係ツリーがある場合は、バージョンを更新するために を編集しているときに、推移性もpom.xml
修正する必要があります。
私の知る限り、現在、必要なものの検証をサポートするエンフォーサ ルールはありません。
次のようなエンフォーサ ルールを作成することをお勧めします。ensureTransitiveVersionRangesArePinned
そのルールは次のことを行う必要があります。
- プロジェクトの依存関係のリストをスキャンする
- 各プロジェクトの依存関係によって提供される推移的な依存関係を計算します
- これらの推移的な依存関係のいずれかがバージョン範囲である場合
exclusion
その推移的な依存関係があることを検証します
- 直接的なプロジェクトの依存関係として固定された推移的な依存関係のバージョンがあることを検証します (別の GAV にある同等のアーティファクトを追加している可能性があるため、固定されたバージョンがなくても失敗ではない可能性があります。依存関係)... いずれにせよ、依存関係が追加されていない場合、ほとんどの場合、単体テストは CNFE をトリガーすることによってそれをキャッチする必要があるため、このチェックは厳密には必須ではありませんが、おそらく警告を出力する必要があります。
実際に推移的な依存関係を除外していることを確認するツールがあるかどうか思い出せない<exclusions>
ので、調査する必要があるかもしれません。