Переупаковка пакетов в Gradle

[@advance]

Спасибо за статью. Тоже решал данную проблему лет 5 назад, но в рамках android и пользовался jarjar вручную. Сегодня, конечно, сама проблема уже не актуальна если говорить о android.
В Вашем случае другая ситуация, но по той же причине.

Я так и не смог выяснить точную причину, почему не получается зафорсить версию asm-а, хотя команда ./gradlew app:dependencies показывает, что версия заменилась на 7.2

То, с чем Вы столкнулись- перегрузка классов. Если Ваше приложение\плагин имеет классы, которые по именам и пакетам совпадают с теми, которые уже содержит рантайм (в Вашем случае- Gradle)- они не будут грузиться в память так как они там уже есть. Иными словами- конфликты классов решаются в сторону рантайма и, как итог, Ваш плагин обращается к классам Gradle, а не к классам Вашей библиотеки.

Зафорсить не получится потому, что байткод Gradle уже собран с зависимостью от asm 6 (по ссылке уже 7.1). Тут либо самому собирать Gradle из исходников c нужной зависимостью в надежде ничего не сломать, либо искать версию Gradle с asm 7.2 из коробки (если такая есть), либо пользоваться той версией asm, что поставляется с Gradle.

Ну или можно поступить так, как Вы- перепаковать либу или подвергнуть ее обфускации

[@panman]

Но в таком случае как вы объясните то, что плагин корректно работает на тестовых и pet проектах с точно такой же версией Gradle, как и на проекте где плагин не работает?
В рабочем проекте есть robolectric, kryo, они и используют asm другой версии (возможно какая-нибудь еще либа). Я думаю тут конфликт версий asm-а связан именно со сторонними библиотеками, а не а с градлом.

[@advance]

Сложно сказать. Надо сравнивать конфигурации Ваших проектов и что в них происходит. Если даже дело не в самом Gradle- могу предположить, что какой-то плагин, который уже содержит asm, подключается раньше Вашего.

Быстрый гуглеж подсказывает, что это весьма вероятно. Например, вот так подключается asm в kotlin-android-extensions. И, судя по всему, по этой зависимости подключается версия asm с патчами для IntelliJ.

Я не уверен, но, возможно, это может стать решением и для Вас

[@sshikov]

>Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала.
А что, плагин разве не имеет своего класслоадера?

[@panman]

Интересный вопрос. Судя по всему нет, нашел это:

It’s important to understand that a Gradle plugin does not run in its own, isolated classloader.

[@sshikov]

Как-то это довольно странно. Мавеновский плагин, чисто для примера. имеет свой собственный класслоадер. Если в API плагина ничего от упомянутых asm и т.п. не торчит (а оно по-идее не должно) — то это должно радикально решать подобные проблемы.