Прежде всего, один и тот же артефакт не использует разные версии одной и той же зависимости.
+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-beanutils:commons-beanutils:1.9.2
+-commons-collections:commons-collections:3.2.1
and
+-ProjectA:B:0.1
+-commons-validator:commons-validator:1.6
+-commons-collections:commons-collections:3.2.2
Зависимость commons-validator:commons-validator:1.6
использует commons-collections:commons-collections:3.2.2
напрямую и commons-collections:commons-collections:3.2.1
транзитивно (зависимость от другой зависимости). Посредническое посредничество Maven разрешит этот конфликт на основе новейшего принципа. Взгляните на это:[1] Механизм зависимости [2] Посредничество зависимостей и разрешение конфликтов
Правило зависимость-конвергента maven-inspecer-plugin работает нормально. Как говорится в документации :
Это правило требует, чтобы номера версий зависимостей сходились. Если у проекта есть две зависимости, A и B, каждая из которых зависит от одного и того же артефакта, C, это правило не выполнится при сборке, если A зависит от другой версии C, тогда версия C зависит от B.
Поскольку commons-validator (A) и commons-beanutils (B) в зависимости от commons-collection (C) и этих зависимостей имеют разные версии, это поведение вполне разумно.
Вы сами решаете, что вы хотите
Продолжайте использовать правило зависимостей и устраните эту ошибку
В этом случае просто определите commons-collections
, commons-logging
и commons-validator
в <dependencyManagement>
разделе и поместите эти зависимости какуправляемые зависимости в вашем проекте.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</dependency>
</dependencies>
Я думаю, что это требует большой перегрузки, и через некоторое время модель вашего проекта станет неуправляемой. С другой стороны, правило Dependency Mediation
решает эту проблему.
Используйте другое правило, например requireUpperBoundDeps
Это правило предназначено для исследования, если разрешенная зависимость во время сборки ниже, чем все объявления переходной зависимости. Например, он потерпит неудачу, если ваш проект зависит от commons-collections:3.0
, но commons-validator
требует более новой версии commons-collections:3.2.2
<dependencies>
<dependency>
<groupId>commons-validator</groupId>
<artifactId>commons-validator</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.0</version>
</dependency>
</dependencies>
Забудьте о принудительном применении и доверии к посредничеству зависимости
Почти во всех случаях этоправильное решение, потому что Dependency Mediation
работает нормально.