Spring (Boot) & Gradle build dependency management

Столкнулся недавно со следующей ситуацией:

Примерная структура проеткта:

как только я добавил some-data-repo-subproject в зависимости для spring-boot-subproject, внезапно поломались все тесты. По стектрейсу удалось нагуглить, что проблема в том, что spring-boot-стэк (той версии, что у нас в проекте), в частности spring-data, использует драйвер для Кассандры версии 2.x, который не умеет работать с Кассандрой 3.x из-за некоторых изменений. Суть в том, что с одной стороны, при разрешении зависимостей проект spring-boot-subproject, зависящий от some-data-repo-subproject, подхватывает все зависимости some-data-repo-subproject и может их использовать, но также он имеет свои собственные зависимости и в частности его 2.x драйвер «перекрывает» собой драйвер 3.x.

По мне так это крайне мудацкое поведение. Gradle позволяет исключить из зависимости её под-зависимости, я пробовал исключить спринговый драйвер Кассандры нагуглёнными примерами, но не помогло. Да и гуглить сложно: большинство результатов про то как _подключить_, а нее наоборот.

Решил проблему в итоге тем, что добавил в зависимости spring-boot-subproject ту же версию драйвера, что и в some-data-repo-subproject. Но это какое-то костыльное решение.

Вопроса 2:

1) Можно ли настроить Gradle (в идеале, в одном месте — в root-project) так, чтобы он не пробрасывал под-зависимости под-проектов, а собирал их как-то более независимо и модульно, чтобы таких неявных перекрытий не происходило? (Возможно тут дело не в Gradle, а в самой Java, просветите)

2) Как правильно исключить спринговый драйвер Кассандры из spring-boot-стэка, чтобы он его не подтягивал?

P.S. Прошу не советовать обновить spring-boot до актуальной версии, т.к. во-первых, это не решение, во-вторых там есть некоторые изменений в API, в частности в аннотациях, с которыми я уже день провозился в отдельной Git-ветке, но пока что не до того, чтобы мерджить её в основные ветки.

0

korvin_, подключи spring-boot bom ко всем подпроектам, например через subprojects в руте, тогда везде будут одни и те же версии. на самом деле он у тебя наверно подрублен неявно в boot подпроекте, если там применен spring boot плагин

вариант б - можно заэксклудить в бутовом проекте зависимость, в гугле куча инфы по запросу gradle exclude transitive dependency

dependencies { compile('com.example.m:m:1.0') { exclude group: 'org.unwanted', module: 'x' } compile 'com.example.l:1.0' }

Добавлено через 2 минуты
на самом деле лучше всего первый вариант. потом в корневом проекте и бутовом подпроекте апаешь версию бута и мигрируешь немного код

Сообщение от korvin_ во-первых, это не решение

на самом деле решение, ибо сколько не пользовался и сколько не мигрировал особо проблем не было с

Сообщение от korvin_ там есть некоторые изменений в API, в частности в аннотациях

Добавлено через 52 секунды
тут на самом деле лучше по чаще апать версию что бы перепрыгиваний больших не было. а то скоро вон уже второй бут выйдет

1

Сообщение от LeX подключи spring-boot bom ко всем подпроектам

Что это и зачем мне это во всех подпроектах?

Сообщение от LeX применен spring boot плагин

Применён.

Сообщение от LeX вариант б - можно заэксклудить в бутовом проекте зависимость, в гугле куча инфы по запросу gradle exclude transitive dependency

Я пробовал, возможно как-то не так заэксклюдил или недозаэксклюдил что-то. Вот кусок build.gradle:

оно не сработало.

Сообщение от LeX ибо сколько не пользовался и сколько не мигрировал особо проблем не было с

Хз, может, у нас спрингбутовый проект неправильно реализован, не я его разрабатывал, но когда попробовал апнуть версию, пришлось долго разбираться с изменениями в этой аннотационной магии.

0

Сообщение от korvin_ Вот кусок build.gradle:

у maven есть комманда mvn dependency:tree, которая показывает откуда пришла каждая зависимосить. Обычно проблемы с перекрытием версий отлавливаются такой коммандой. Думаю в градле есть нечто подобное.

1

Сообщение от KEKCoGEN у maven есть комманда mvn dependency:tree, которая показывает откуда пришла каждая зависимосить. Обычно проблемы с перекрытием версий отлавливаются такой коммандой. Думаю в градле есть нечто подобное.

Точно, не подумал об этом. Главное теперь — после новогодних праздников вспомнить.

0

В гредле есть project report плагин, там можно посмотреть откуда еще тянется зависимость.

Что это и зачем мне это во всех подпроектах

Bom предоставляет набор версий либ, которые протестированы для взаимодействия друг с другом, и.е. разрабы бута говорят что с этими версиями все будет работать. В самом проекте эффект следующий, при объявлении зависимостей версия не пишется, она подтянется сама

0

Сообщение от LeX В самом проекте эффект следующий, при объявлении зависимостей версия не пишется, она подтянется сама

1) Чем это отличается от того, что я не буду указывать конкретную версию спринг-бута?
2) Мне не нужен спринг-бут и всё, что с ним связано, во всех подпроектах.

0

1. Ты будешь использовать версии зависимостей с ним совместимые
2. Ты не подключаешь бут ко всем проектам, ты подключаешь только бом с совместимым версиями, сами зависимости будет подключены только те, которые пропишешь

Что тут собственно объяснять, ты вроде взрослый мальчик опытный разработчик, гуглить наверно умеешь

0

Сообщение от LeX Bom предоставляет набор версий либ, которые протестированы для взаимодействия друг с другом

это хорошо работает до того момента пока тебе не нужна новая версия либы из BOM, или либа, которая там не указанна. Обычно проблемы с версиями начинаются именно с таких кейсов.

Добавлено через 4 минуты
Кстати не все проблемы с перекрытиями версий возможно решить исключением проблемной зависимости. У меня был случай что некая либа работала со старой версией httpclient (вроде бы) и когда я подключил очередную зависимость, более новая версия httpclient перекрыла старую и старая либа перестала работать. Когда я исключил новый httpclient, перестала работать новая либа. Выяснилось что некоторая часть httpclient не имеет обратной совместимости. Пришлось тащить сорсы httpclient, править проблемный метод и заворачивать его в свой кастомный httpclient....dependency hell во всей красе

0