Разрешение зависимостей Maven (конфликтующее)

Допустим, у меня есть четыре проекта:

Проект A (зависит от B и D)
Проект B (зависит от D)
Проект C (зависит от D)
Проект D

В этом сценарии, если я запускаю проект A, Maven правильно разрешит зависимость от D. Если я правильно понимаю, Maven всегда берет зависимость с кратчайшим путем. Поскольку D является прямой зависимостью от A, она будет использоваться вместо D, который указан в B.

Но теперь предположим, что структура:

Проект A (зависит от B и C)
Проект B (зависит от D)
Проект C (зависит от D)
Проект D

В этом случае пути к разрешению D имеют одинаковую глубину. То, что происходит, - то, что у Maven будет конфликт. Я знаю, что можно сказать Мавену, что он должен исключить зависимости. Но мой вопрос, как решить такие проблемы. Я имею в виду, что в реальных приложениях у вас много зависимостей и, возможно, много конфликтов.

Является ли решение наилучшей практики действительно исключать вещи или есть другие возможные решения для этого? Мне очень трудно иметь дело с тем, когда я неожиданно получаю исключение ClassNotFound, потому что некоторые версии изменились, из-за чего Maven взял другую зависимость. Конечно, знание этого факта позволяет легко догадаться, что проблема в конфликте зависимостей.

Я использую Maven 2.1-SNAPSHOT.

Ответ 1

Способ решения таких ситуаций, как это, заключается в том, чтобы включить раздел <dependencyManagement> в корневой pom вашего проекта, где вы указываете, какая версия библиотеки будет использоваться.

EDIT:

<dependencyManagement>
  <dependencies>
    <dependency>
        <groupId>foo</groupId>
        <artifactId>bar</artifactId>
        <version>1.2.3</version>
    </dependency>
   </dependencies>
</dependencyManagement>

Теперь, независимо от того, какая версия библиотеки foo: bar запрашивается зависимостью, версия 1.2.3 всегда будет использоваться для этого проекта и всех подпроектов.

Справка:

Управление зависимостями

Ответ 2

Maven может обрабатывать обе ситуации без каких-либо конфликтов. Конфликты будут существовать, когда требуются две версии транзитивной зависимости. ClassNotFoundException вы описываете результаты приложения (или зависимости), пытающегося использовать класс, недоступный в версии конфликтуемой зависимости, которая фактически используется. Существует несколько способов устранения проблемы.

Обновите версии используемых вами библиотек, которые зависят от конфликтной зависимости, поэтому все они зависят от версии той же версии этой зависимости
Объявить конфликтную зависимость как прямую зависимость вашего проекта с версией, которую вы хотите включить (в примере, с отсутствующим классом, включенным в нее)
Укажите, какая версия конфликтной зависимости, которую должны использовать транзитивные зависимости, через раздел <dependencyManagement> POM
Явно исключаю, чтобы нежелательные версии конфликтной зависимости включались в зависимости от зависимостей, которые полагаются на них, используя <exclusion>

Ответ 3

Это принципиально не проблема maven, а проблема Java. Если для проекта B и проекта C требуются две несовместимые версии проекта D, вы не можете использовать их как в проекте A.

Способ Maven разрешения таких конфликтов, к сожалению, как вы уже знаете, выбрать, какие из них исключить.

Использование mvn dependency:analyze и mvn dependency:tree помогает найти, какие конфликты у вас есть.

Ответ 4

Вы можете enforce согласованные зависимости во всем проекте с правилом Dependency Конвергенция.

 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-enforcer-plugin</artifactId>
     <version>1.3.1</version>
     <executions>
        <execution>
           <id>enforce</id>
           <configuration>
              <rules>
                 <DependencyConvergence/>
              </rules>
           </configuration>
           <goals>
              <goal>enforce</goal>
           </goals>
        </execution>
     </executions>
  </plugin>

Ответ 5

Одна из возможных стратегий - указать для основного проекта, какую версию D использовать (новейшую, например,). Однако, если библиотека D не поддерживает обратную совместимость, у вас есть проблема, о которой говорит kukudas - невозможно использовать обе библиотеки в вашем проекте.

В такой ситуации может потребоваться использование B или C в более старой версии, так что оба будут зависеть от совместимых версий D.