Комментарии 9
Меня удивляет, что такой продвинутый инструмент как java + gradle до сих пор не умеют в изоляцию графов зависимостей библиотек и проекта. Это кажется ужасной глупостью. Неужели нельзя было сделать какой нибудь дополнительный префикс к классу из пакета библиотеки, чтобы на уровне jvm не возникало конфликтов.
Иметь две разные библиотеки еще большая глупость. Представьте что это библиотеки логирования, тогда для каждой нужна своя конфигурация. И у каждой будет свой файл с логами. А если это ОРМ, то у нас будет несколько транзакций, несколько копий entity, это точно не взлетит.
Ну очевидно что это должно быть опцией, а не принудительным вариантом. Но это вовсе не глупость - вот ты завязан на библиотеке от вендора/государства/легаси - а она осталась жить на старой версии зависимости - всё, ты блокирован в обновлении. В то время как иметь у себя две разных версии exoPlayer, rx. С orm тоже проблем не вижу - если библиотека пишет в ту-же таблицу что и ваш модуль - это что-то неадекватное, а если у неё своя таблица - какая вообще разница что там разные версии)
Если орм то это же не просто пишет в ту-же табличку это и определения классов, и транзакции (а управление ими это совсем другая бибилиотека у которой тоже свои требования к версии) и много еще чего.
Все-таки самый простой вариант - оставить одну бибилиотеку. А если апи не слишком изменилось, то оно может заработать и так. Или какую-то простенькую прокладку написать.
Ключевое "может и заработать" - если повезёт, может быть. Это не бизнесовый подход - есть масса ситуаций когда например бизнесу нужно чтобы банковский модуль у вас был чужой - потому что там дешевле, а он тащит за собой конфликтные зависимости. И вы вынуждены с каждым обновлением подстраиваться и молиться.
Прь орм кстати всё таки не представляю кейс - был бы вам очень благодарен если вы прямо конкретный вариант конфликта опишите - я как будто что-то упускаю. Ну то есть орм ведь маппит таблицы и сущности на классы, но вы не лезете в базу либы (где другая версия орм), а общаетесь с ней классами которые она вам отдаёт, а даже если вы их в свою таблицу запишите и они смапятся там по другому, обратно то вы всё равно в либу отдадите класс на уровне jvm понимаемый либой (с префиксом).
Разве что realm какой нибудь, который не предоставляет реальные объекты, а лишь ленивые дата провайдеры, но даже с ним проблема решается вызовом copyFromRealm, да я и не знаю, что это за лютая либа, которая живые объекты рилма будет отдавать.
вот ты завязан на библиотеке от вендора/государства/легаси - а она осталась жить на старой версии зависимости - всё, ты блокирован в обновлении.
Вы не представляете, насколько это реальный и типичный случай. Зачастую все даже еще хуже - потому что например, новая версия библиотеки, с одной стороны, не содержит уязвимостей, а с другой - требует более новой версии JVM. Ну или еще типовой неприятный случай - есть у вас скажем spring web, в которой в наличии кучка уязвимостей. Но - эти уязвимости - они в реализации серверной части, а вы используете например только RestTemplate, т.е. у вас клиент. Но при этом авторы оного spring web не подумали о таком сценарии, и разделили код так как разделили - то есть никак. И в одном компоненте лежит и серверная часть, и клиентская. И вот сидишь ты такой, и думаешь, как же мне доказать безопасникам (или сканеру типа SAST), что у тебя-то в приложении никаких уязвимостей нет, потому что кроме RestTemplate ничего не используется.
Ну и кстати, никакой BOM тут не помогает от слова совсем.
Можно через Shadow плагин, но нужно руками все прописывать. Условно скинуть свой подграф в один Gradle модуль, применть Shadow с relocate и зависить в дальнейшем от него.
Ну, сделать префикс к классу (или еще лучше - поменять пакет) может разработчик библиотеки. И это означает сломать API, вообще говоря. У такого подхода есть свои недостатки.
А пользователь библиотеки ограничен средствами системы сборки. Он может например использовать maven shade плагин, который сделает ровно то, что вы предлагаете (ну если я вас верно понял). А еще есть OSGI, где можно иметь несколько версий библиотек. достаточно несложно.
Я столкнулся с тем, что если у некоторых компонентов (отдельных java проектов) файл build.gradle (да и сам gradle) не обновлялся достаточно давно, то задействование bom с помощью platform (и тем более force platform) приносит кучу проблем, по сути ломая механизм разрешения зависимостей. Так что лучше перед использованием bom избавиться от зоопарка версий gradle (если он конечно есть), а также привести скрипты build.gradle к "общему знаменателю" - убрать, например, compile/runtime и другие устаревшие штуки.
Создание и использование BOM в Gradle