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

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

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

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

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

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

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


dependencies version maven-3 transitive-dependency
person lisak    schedule 08.06.2011    source источник
comment
Если вы хотите определить зависимость для теста, дайте ее только через область, которая также работает во время выполнения.   -  person khmarbaise    schedule 21.07.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

arrow_upward
1
arrow_downward

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

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

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

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

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

person Huluvu424242    schedule 12.01.2012