В своей статье хочу рассказать об очередной хитрости, которую можно довольно просто реализовать с помощью Gradle — переупаковке пакетов библиотек. Каждый, кто хоть чуть чуть работал с этой системой сборки, знает, что она автоматически умеет решать конфликты разных версий библиотек, а при желании можно повлиять на это, например зафорсить конкретную версию какой-нибудь библиотеки: К сожалению, это не всегда помогает решить проблему конфликта версий. Например, есть известная проблема, что некоторые устройства htc в прошивке уже имеют библиотеку gson и если ваша версия gson-а отличается от встроенной, то могут возникнуть проблемы, так как ClassLoader загрузит в память только один класс и в данном случае это будет системный. Такая проблема также может возникнуть и при разработке библиотек. Если вы подключите в свой проект 2 библиотеки, использующие одну и ту же стороннюю библиотеку разных версий, например 1 и 2, то Gradle разрулит и возьмет самую новую версию, вторую. Но если в этой сторонней библиотеке нет обратной совместимости и вторая версия не может быть просто так использована вместо первой, то будут проблемы, которые наверняка будет очень сложно отследить по стектрейсу. Библиотека, ожидающая первую версию, получит классы второй и просто упадет. Я столкнулся с конфликтом версий при написании градл плагина, в нем используется библиотека asm, которая и конфликтовала. После написания плагина, я проверил его работоспособность на тестовом проекте: все отлично, проверил на pet project-е, тоже все хорошо, но когда подключил к реальному рабочему проекту с кучей сторонних зависимостей, столкнулся с проблемой.  Решение проблемы под катом. Выведем полный стектрейс ошибки:  Видим, что ошибка в конструкторе класса библиотеки asm ClassVisitor на 79 строке. Заглянем туда, но при попытке открыть ClassVisitor, студия предложила 2 варианта  В моем плагине используется asm версии 7.2, значит идем туда и на 79 строке видим следующее:  Это явно не то, что нам нужно. Теперь идем в ClassVisitor 6 версии:  Как раз наш IllegalArgumentException без сообщения. Мой плагин использует ASM api 7 версии Opcodes.ASM7, а в 6 версии библиотеки этого api еще не существует, поэтому и вылетает IllegalArgumentException в конструкторе. Можно сделать вывод, что плагин получает не вернную версию библиотеки. Херня вопрос, подумал я и сделал так: К моему сожалению это не дало абсолютно никакого эффекта. Я так и не смог выяснить точную причину, почему не получается зафорсить версию asm-а, хотя команда ./gradlew app:dependencies показывает, что версия заменилась на 7.2. Если у кого-то есть мысли или предположения, буду рад услышать мнение. Началась череда гугления и углубления в работу градла. В итоге, пошел на сайт asm-а, может они что-то знаю по этому поводу. Оказалось, что действительно знают, ответ на мой вопрос оказался в разделе FAQ. Говорят подменить пакет asm-а на другой, даже предлагают для этого утилиту. Ок, попробуем. Нужно лишь подключить плагин и сделать небольшую настройку: build/jarjar в данном случае директория, в которую будет сгенерирован jar файл библиотеки asm с переупакованными пакетами, поэтому нужно открыть доступ зависимостей в эту директорию через fileTree. Теперь библиотека будет доступна с импортом stater.org.objectweb.asm.* вместо org.objectweb.asm.*. У этого плагина есть еще различные настройки, но в моем примере хватило просто смены пакетов.  Далее идем по всему проекту и меняем везде импорты с org.objectweb.asm на
stater.org.objectweb.asm. На мой взгляд очень удобная утилита, в разы проще чем делать это руками, тем более что при обновлении библиотеки, мы просто меняем from 'org.ow2.asm:asm:7.2' на новую версию и переупакованный jar-ник с новой версией сгенерится на автомате. Если у вас просто проект (не библиотека), то этого вам будет достаточно, чтобы разрешить неразрешимые конфликты, типо gson-а, упомянутого в начале статьи. Но если вы, как и я, пишите библиотеку, то это не все. Проблему с переупаковкой мы решили, но теперь asm подключен к проекту не через зависимость от удаленного maven репозитория, а через локальный jar файл, который просто потеряется при деплое вашей библиотеки и будет такая ошибка NoClassDefFoundError. Но эту проблему решить довольно просто: В нашем gradle файле создаем новую конфигурацию: Далее меняем  на Переопределяем таску, которая отвечает за сбор вашего итогового jar файла и записываем все библиотеки с нашей новой конфигурацией в итоговый jar-ник: Вот и все, деплоим наш плагин как и раньше, подключаем к проекту, где были неразрешимые конфликты и все отлично работает.
Такая переупаковка делает нашу библиотеку более отказоустойчивой при подключении к различного рода проектам с другими библиотеками. Плохая идея, ни к чему хорошему она не приведет. В процессе сборки проекта есть такая интересная таска check...DuplicateClasses, которая просто зарубит файлы с одинаковыми пакетами. То есть файлы полученные из jar файла подключенной библиотеки и файлы из этой же библиотеки, подключенной через удаленный репозиторий. В итоге будет такая ошибка:  На этом все. Спасибо всем, кто дочитал! Тулза для переупаковки
Плагин с примером Android разработчик