Как Maven разрешает конфликты версий транзитивных зависимостей? стратегия ближайших победителей

Question

Я только что привык к тому, что в моих проектах не было задействованных необъявленных или неиспользуемых объявленных зависимостей. Хотя очень сложно отслеживать неиспользуемые объявленные зависимости времени выполнения/теста, которые перечислены в зависимости: анализировать ... Просто нужно писать комментарии к ним в pom.xml или иным образом управлять им, чтобы знать, что они необходимы для тестирования или времени выполнения.

Но путь разрешения конфликтной ситуации по-прежнему остается неясным. Относительно транзитивных зависимостей.

Как работает стратегия ближайших побед? Когда одна версия используется над другой версией?

• Если вы объявляете б необъявленной зависимости с номером версии - она ​​всегда побеждает

• Если не указать версию зависимостей явно, Maven не может разрешить любой версии конфликтов, которые могут возникнуть в отношении этой зависимости (странно, но написано here)

• Если вы не объявляете Необъявленная используется зависимость, она выбирает переходную зависимость от ближайшего уровня (ближайших побед стратегии), и если конфликт находится на том же уровне, то это как-то решает б etween версии над версией B ... Может быть, первый один он приходит при обработке depenencies выигрывает

Answer 1

Я думаю, что разрешение зависимостей работает точно так же, как вы описали.

Я также думаю, что ваша жизнь была бы намного проще, если вы используете <scope> ребенка тег в <dependency>

, как цитата из Maven официального сайта:

1. компиляции: Это сфера по умолчанию, используется, если ни один не указан. Зависимости компиляции доступны во всех классах проекта. Кроме того, эти зависимости распространяются на зависимые проекты.
2. предоставлено: Это похоже на компиляцию, но указывает, что вы ожидаете, что JDK или контейнер предоставят зависимость во время выполнения. Например, при создании веб-приложения для Java Enterprise Edition вы должны установить зависимость от API-интерфейса Servlet и связанных с ним API-интерфейсов Java EE для области видимости, поскольку веб-контейнер предоставляет эти классы. Эта область видимости доступна только в классе компиляции и теста, и не является транзитивной.
3. runtime Эта область указывает, что зависимость не требуется для компиляции, но предназначена для выполнения. Он находится в среде выполнения и тестирует пути к классам, но не компилирует classpath.
4. test: Эта область указывает, что зависимость не требуется для нормального использования приложения и доступна только для фаз компиляции и выполнения теста.
5. system: Этот объем подобен предоставленному, за исключением того, что вы должны предоставить JAR, который содержит его явно. Артефакт всегда доступен и не просматривается в репозитории.
6. импорт: (доступно только в Maven 2.0.9 или новее) Эта область используется только для зависимости типа pom в разделе. Он указывает, что указанный POM должен быть заменен зависимостями в этом разделе POM. Поскольку они заменяются, зависимости с объемом импорта фактически не участвуют в ограничении транзитивности зависимости.

Answer 2

Есть некоторые ссылки на документацию управления зависимостями:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html (importend таблица в разделе «рамках зависимостей»)

Есть бог статья в немецком журнале, которые описывают решение зависимости - здесь являются BibTeX исх статьи: http://www.bibsonomy.org/bibtex/2ef10bb1bc1be7806bc3fba53417bbd5f/funthomas424242

есть раздел о плагине зависимостей в Sonatype книге по адресу: http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html

Я надеюсь, что это было полезно.