Как стать автором
Обновить

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

Время на прочтение4 мин
Количество просмотров3.8K

В своей статье хочу рассказать об очередной хитрости, которую можно довольно просто реализовать с помощью Gradle — переупаковке пакетов библиотек. Каждый, кто хоть чуть чуть работал с этой системой сборки, знает, что она автоматически умеет решать конфликты разных версий библиотек, а при желании можно повлиять на это, например зафорсить конкретную версию какой-нибудь библиотеки:


configurations.all {
    resolutionStrategy {
        force "org.ow2.asm:asm:7.2"
    }
}

К сожалению, это не всегда помогает решить проблему конфликта версий. Например, есть известная проблема, что некоторые устройства 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 в конструкторе. Можно сделать вывод, что плагин получает не вернную версию библиотеки.


Херня вопрос, подумал я и сделал так:


configurations.all {
    resolutionStrategy {
        force "org.ow2.asm:asm:7.2"
    }
}

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


Проблему надо как-то решать


Началась череда гугления и углубления в работу градла. В итоге, пошел на сайт asm-а, может они что-то знаю по этому поводу. Оказалось, что действительно знают, ответ на мой вопрос оказался в разделе FAQ. Говорят подменить пакет asm-а на другой, даже предлагают для этого утилиту. Ок, попробуем. Нужно лишь подключить плагин и сделать небольшую настройку:


apply plugin: 'org.anarres.jarjar'
...
dependencies {
    implementation fileTree(dir: 'build/jarjar', include: ['*.jar'])
    implementation jarjar.repackage('asm') {
        from 'org.ow2.asm:asm:7.2'
        classRename "org.objectweb.asm.**", "stater.org.objectweb.asm.@1"
    }
}

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. Но эту проблему решить довольно просто:


  1. В нашем gradle файле создаем новую конфигурацию:


    configurations {
        extraLibs
        implementation.extendsFrom(extraLibs)
    }

  2. Далее меняем


    implementation fileTree(dir: 'build/jarjar', include: ['*.jar'])

    на


    extraLibs fileTree(dir: 'build/jarjar', include: ['*.jar'])

  3. Переопределяем таску, которая отвечает за сбор вашего итогового jar файла и записываем все библиотеки с нашей новой конфигурацией в итоговый jar-ник:


    jar {
      from {
        configurations.extraLibs.collect { it.isDirectory() ? it : zipTree(it) }
      }
    }


Вот и все, деплоим наш плагин как и раньше, подключаем к проекту, где были неразрешимые конфликты и все отлично работает.
Такая переупаковка делает нашу библиотеку более отказоустойчивой при подключении к различного рода проектам с другими библиотеками.


А если просто подключить jar файл конфликтующей библиотеки к плагину без переупаковки?


Плохая идея, ни к чему хорошему она не приведет. В процессе сборки проекта есть такая интересная таска check...DuplicateClasses, которая просто зарубит файлы с одинаковыми пакетами. То есть файлы полученные из jar файла подключенной библиотеки и файлы из этой же библиотеки, подключенной через удаленный репозиторий. В итоге будет такая ошибка:



На этом все. Спасибо всем, кто дочитал!


Тулза для переупаковки
Плагин с примером

Теги:
Хабы:
Всего голосов 12: ↑11 и ↓1+10
Комментарии6

Публикации

Истории

Работа

Java разработчик
347 вакансий

Ближайшие события

7 – 8 ноября
Конференция byteoilgas_conf 2024
МоскваОнлайн
7 – 8 ноября
Конференция «Матемаркетинг»
МоскваОнлайн
15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань