Comments 6
Спасибо за статью. Тоже решал данную проблему лет 5 назад, но в рамках android и пользовался jarjar вручную. Сегодня, конечно, сама проблема уже не актуальна если говорить о android.
В Вашем случае другая ситуация, но по той же причине.
Зафорсить не получится потому, что байткод Gradle уже собран с зависимостью от asm 6 (по ссылке уже 7.1). Тут либо самому собирать Gradle из исходников c нужной зависимостью в надежде ничего не сломать, либо искать версию Gradle с asm 7.2 из коробки (если такая есть), либо пользоваться той версией asm, что поставляется с Gradle.
Ну или можно поступить так, как Вы- перепаковать либу или подвергнуть ее обфускации
В Вашем случае другая ситуация, но по той же причине.
Я так и не смог выяснить точную причину, почему не получается зафорсить версию asm-а, хотя команда ./gradlew app:dependencies показывает, что версия заменилась на 7.2То, с чем Вы столкнулись- перегрузка классов. Если Ваше приложение\плагин имеет классы, которые по именам и пакетам совпадают с теми, которые уже содержит рантайм (в Вашем случае- Gradle)- они не будут грузиться в память так как они там уже есть. Иными словами- конфликты классов решаются в сторону рантайма и, как итог, Ваш плагин обращается к классам Gradle, а не к классам Вашей библиотеки.
Зафорсить не получится потому, что байткод Gradle уже собран с зависимостью от asm 6 (по ссылке уже 7.1). Тут либо самому собирать Gradle из исходников c нужной зависимостью в надежде ничего не сломать, либо искать версию Gradle с asm 7.2 из коробки (если такая есть), либо пользоваться той версией asm, что поставляется с Gradle.
Ну или можно поступить так, как Вы- перепаковать либу или подвергнуть ее обфускации
Но в таком случае как вы объясните то, что плагин корректно работает на тестовых и pet проектах с точно такой же версией Gradle, как и на проекте где плагин не работает?
В рабочем проекте есть robolectric, kryo, они и используют asm другой версии (возможно какая-нибудь еще либа). Я думаю тут конфликт версий asm-а связан именно со сторонними библиотеками, а не а с градлом.
В рабочем проекте есть robolectric, kryo, они и используют asm другой версии (возможно какая-нибудь еще либа). Я думаю тут конфликт версий asm-а связан именно со сторонними библиотеками, а не а с градлом.
Сложно сказать. Надо сравнивать конфигурации Ваших проектов и что в них происходит. Если даже дело не в самом Gradle- могу предположить, что какой-то плагин, который уже содержит asm, подключается раньше Вашего.
Быстрый гуглеж подсказывает, что это весьма вероятно. Например, вот так подключается asm в kotlin-android-extensions. И, судя по всему, по этой зависимости подключается версия asm с патчами для IntelliJ.
Я не уверен, но, возможно, это может стать решением и для Вас
Быстрый гуглеж подсказывает, что это весьма вероятно. Например, вот так подключается asm в kotlin-android-extensions. И, судя по всему, по этой зависимости подключается версия asm с патчами для IntelliJ.
Я не уверен, но, возможно, это может стать решением и для Вас
>Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала.
А что, плагин разве не имеет своего класслоадера?
А что, плагин разве не имеет своего класслоадера?
Интересный вопрос. Судя по всему нет, нашел это:
It’s important to understand that a Gradle plugin does not run in its own, isolated classloader.
Sign up to leave a comment.
Переупаковка пакетов в Gradle