Теневая банка Gradle с конфликтующими зависимостями

Я обдумываю идею создания убер-банок для своих услуг, но меня беспокоит включение банок с конфликтующими зависимостями. Что происходит, когда jar A зависит от slf4j-1.0, а jar B зависит от slf4j-2.0, и между версиями 1.0 и 2.0 произошли серьезные изменения? Когда эти банки оба включаются в банку uber, мне нужно писать определенные фильтры по пространству имен или что-то происходит во время теневого процесса, который создает пространства имен для банок?

Спасибо за помощь


gradle build.gradle uberjar
person bjoern    schedule 04.06.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы правильно беспокоитесь. В конечном итоге вы сталкиваетесь с коллизиями (коллега назвал это «снова ад dll»), и иногда вы можете иметь классы как из v1, так и из v2 в одном и том же каталоге в файле jar.

Вы можете легко исключить одну или другую версию, но если вашим зависимостям нужны обе версии, вы столкнетесь со следующими вариантами:

  • найти новую зависимость, которая не имеет конфликта
  • обновить или понизить текущую зависимость, чтобы привести версии в соответствие
  • отправить как военный файл или какой-либо другой тип файла, который лучше справляется с этим, включая обычный jarfile с манифестом, который включает путь к классам
  • рассмотрите весеннюю загрузку, которая использует стратегию, отличную от затенения: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#executable-jar

Что бы вы ни делали, зависимости Gradle полезны.

person mooreds    schedule 07.04.2015