Ну, надо конечно, запилить топик ярости с такой картинкой:
И вот там и пообщаемся.
И потом, зачем останавливаться на OSGi? раз уж по вашему принципу мы ищем кардинальное решение «Разрешение конфликтов в транзитивных зависимостях», то можем, например, перестать писать на языках, в которых эта проблема есть. Решать, так решать!
Ну а пока что, я бы хотел остаться в контексте этого топика, который, всё таки, по системам сборки.
OSGi является совершеннейшим оффтопиком в данной теме :)
Де факто, чаще всего мы сегодня собираем обычные Java приложения, без OSGi и Jigsaw. И чаще всего, достаточно предотвратить конфликты таким образом как описано в посте, чтобы приложение заработало as designed.
Ну, если есть ограничение сверху, то это ничего не решает, потому что если версия конфликтующей зависимости выпадает из диапазона, то здравствуй, nearset.
Да, это неплохая замена fail.
Мы всё еще остаемся а адом exclusions, но можно знать что прописать в dependency management.
Да, пожалуй пойдет. Сейчас проапдейчу пост.
Shading заточен не под обход nearest, а под обход конфликта, когда нужны обе версии класса. Этакий OSGi для бедных. Ужасный, конечно, костыль, но когда не хочется заморачиваться с OSGi — сойдет.
Я про него не писал, потому что слегка out of scope.
а про остальные проблемы, в том числе о пакетах, для которых нельзя одновременно в систему поставить 2 версии, приходите слушать в субботу :) Там их есть ;)
Да-да, «отобрать и запретить» это наше всё. Для всех остальных есть Gradle.
Если серьезно, то по хорошему в билде Грейдла не должно быть никаких тасков вообще. Корпоративный init.gralde apply-ит корпоративный плагин, и всё, проблема решена.
Я, похоже, плохо объяснил как работает fail, за что прошу прощения. Вам не нужно ничего переключать. Когда сборка падает по конфликту, вы либо исключаете D1 (в посте есть пример), либо энфорсите D2 добавив его ручками (просто добавь воды зависимость в скрипт).
И вот там и пообщаемся.
И потом, зачем останавливаться на OSGi? раз уж по вашему принципу мы ищем кардинальное решение «Разрешение конфликтов в транзитивных зависимостях», то можем, например, перестать писать на языках, в которых эта проблема есть. Решать, так решать!
Ну а пока что, я бы хотел остаться в контексте этого топика, который, всё таки, по системам сборки.
Де факто, чаще всего мы сегодня собираем обычные Java приложения, без OSGi и Jigsaw. И чаще всего, достаточно предотвратить конфликты таким образом как описано в посте, чтобы приложение заработало as designed.
Спасибо.
Мы всё еще остаемся а адом exclusions, но можно знать что прописать в dependency management.
Да, пожалуй пойдет. Сейчас проапдейчу пост.
Я про него не писал, потому что слегка out of scope.
Если серьезно, то по хорошему в билде Грейдла не должно быть никаких тасков вообще. Корпоративный init.gralde apply-ит корпоративный плагин, и всё, проблема решена.
водызависимость в скрипт).