Один и тот же артефакт использует разные версии одной и той же зависимости - PullRequest
2 голосов
/ 26 октября 2019

Я использую плагин Maven Enforcer, но обнаружил странный случай сходимости зависимостей:

Dependency convergence error for commons-collections:commons-collections:3.2.1 paths to dependency are:
+-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

И это объявление зависимости:

<dependency>
    <groupId>commons-validator</groupId>
    <artifactId>commons-validator</artifactId>
    <version>1.6</version>
</dependency>

вы можете видеть, что то же самоеАртефакт использует разные версии одной и той же зависимости. Как это может случиться? также единственный способ подавить предупреждение - включить последнюю версию этой зависимости как прямую зависимость в мой pom.

Я что-то упустил?

Ответы [ 2 ]

0 голосов
/ 26 октября 2019

Прежде всего, один и тот же артефакт не использует разные версии одной и той же зависимости.

+-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 работает нормально.

0 голосов
/ 26 октября 2019

Из дерева зависимостей вы видите, что commons-validator:commons-validator:1.6 напрямую зависит от commons-collections:commons-collections:3.2.2, но также имеет транзитивную зависимость от commons-collections:commons-collections:3.2.1. Ничего необычного в этом нет.

Чтобы решить эту проблему, вам нужно выбрать версию. Просто следуйте советам khmarbaise и добавьте запись в раздел <dependencyManagement> вашего POM.

...