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

Question

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

Но способ разрешения конфликта версий для меня все еще неясен.Относительно переходных зависимостей.

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

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

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

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

Answer 1

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

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

как указано на официальном сайте maven:

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

Answer 2

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

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html (таблица значений в разделе "область зависимостей")

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

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

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