Комментарии 14
Мы получаем конфликт версий у библиотеки A, который в дефолтной стратегии Gradle решается таким образом, что в Runtime classpath у нас остаётся библиотека A версии 2.0.
Ок, сейчас мы закрепили с тобой, что Gradle оставит библиотеку A более высокой версии.
Может быть вопрос не стоял бы так остро, если отказаться от дефолтной стратегии Gradle? Что мешает ему указать, что зависимости нужны 2 и не превращать это все в пытку.
Это ещё хорошо если библиотеки конфликтующие находятся под вашей эгидой и там ещё можно что-то сделать
На сколько тяжело следить за этим делом в таком большом проекте ?
Dll hell. - Форточки, пингвин.
Яблоко решило просто - каждая программа несёт с собой, всё, что ей надо.
Более радикально решают этот вопрос контейнеры.
задача не самая простая, но тут думаю лучшая стратегия автоматизировать те проверки, которые можно автоматизировать)
Можете поделиться примером ?
Как раз в своих докладах на мобиусе затрагивал эти проблемы и какие инструменты мы использовали, чтобы их решать)
Один из основных инструментов - https://github.com/Kotlin/binary-compatibility-validator
У нас в kotlin/java продукте много библиотек используется и проблемы поднимаемые в статье раньше тоже часто встречались. В итоге пришли к такому решению:
1. Во всех библиотеках зависимости от остальных библиотек выставлены как provided (т.е. транзитивно не тянутся).
2. Каждая библиотека заливает в maven repo не только себя и исходники, но и тесты отдельной jar'кой
3. Все библиотеки с указанием нужных версий подключены в общем проекте, который билдит родительские pom'ники для всех конечных приложений. Этот общий проект при выполнении тестов так же прогоняет все тесты из подключаемых библиотек. Это позволяет довольно легко отлавливать проблемы с совместимостью ABI.
А может проблема в том, что вместо православных POJO, которыми ты полностью управляешь, используются data-классы, генерируемые неконтролируемым тобою компилятором?
Хоть к Java и не имею отношения, но информация полезная, спасибо. Не хватает только после демонстрации ошибок показать как эти ошибки можно было бы разрулить. Я так понимаю, помимо дефолтного конструктора при добавлении новых публичных свойств нужно реализовать конструктор, имитирующий дефолтный конструктор до того как были добавлены новые свойства. Верно?
В случае с дата классом хороших решений нет, так как у каждого будут свои минусы. Тут более подробно описано - https://jakewharton.com/public-api-challenges-in-kotlin/
Есть также решение в виде компиляторного плагина, который убирает боль работы с дата классами в публичном api библиотеки, но им не пользовались)
Спасибо вам за фидбэк)
API vs ABI: разницу видят не только лишь все