Простой способ отображения и анализа зависимостей buildscript (например, плагинов) в Gradle
Вступление
Это третья часть моего мини-сериала о трюках Gradle, связанных с визуализацией и анализом зависимостей. В первом посте я представил способ отображения зависимостей для всех подпроектов в многопроектной сборке. Во втором я продемонстрировал полезную технику для отслеживания непредвиденных переходных зависимостей в проекте. На этот раз реже используются вещи, но решающие в конкретных случаях — зависимости buildscript.
Реальный вариант использования
Зависимости Buildscript содержат плагины, используемые в нашем проекте, и их зависимости. Казалось бы, ничего интересного, если вы не являетесь разработчиком плагинов Gradle, но это не совсем так. Однажды, будучи консультантом, я исследовал проблему с NoSuchMethodException в большом проекте с пользовательской структурой сборки, построенной поверх Gradle. Проблема возникла только тогда, когда один невинный, очень популярный плагин с открытым исходным кодом был добавлен в проект. Этот же плагин отлично работал во многих других проектах этой компании. В конце я смог выяснить, что одна из зависимостей, используемых в пользовательских скриптах buildSrc переопределяет те же зависимости в более старой версии из плагина. В результате произошел сбой плагина во время выполнения с упомянутой NoSuchMethodException . Чтобы добиться этого, я должен был использовать свой собственный скрипт, так как зависимости buildscript / classpath полностью игнорируются, когда используются ./gradlew dependencies или ./gradlew dependencyInsight .
Решение
Идея написать этот пост возникла в начале 2015 года. Я хотел представить свою небольшую задачу Gradle, которая с помощью некоторых внутренних механизмов Gradle извлекает зависимости buildscript при отображении их на консоли. Пост был отложен, и почти год спустя я был приятно удивлен, читая заметки о выпуске Gradle 2.10. Новая задача buildEnvironment была добавлена.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
$ ./gradlew buildEnvironment:buildEnvironment------------------------------------------------------------Root project------------------------------------------------------------classpath+--- com.bmuschko:gradle-nexus-plugin:2.3\--- io.codearte.gradle.nexus:gradle-nexus-staging-plugin:0.5.3 \--- org.codehaus.groovy.modules.http-builder:http-builder:0.7.1 +--- org.apache.httpcomponents:httpclient:4.2.1 | +--- org.apache.httpcomponents:httpcore:4.2.1 | +--- commons-logging:commons-logging:1.1.1 | \--- commons-codec:commons-codec:1.6 +--- net.sf.json-lib:json-lib:2.3 | +--- commons-beanutils:commons-beanutils:1.8.0 | | \--- commons-logging:commons-logging:1.1.1 | +--- commons-collections:commons-collections:3.2.1 | +--- commons-lang:commons-lang:2.4 | +--- commons-logging:commons-logging:1.1.1 | \--- net.sf.ezmorph:ezmorph:1.0.6 | \--- commons-lang:commons-lang:2.3 -> 2.4 +--- net.sourceforge.nekohtml:nekohtml:1.9.16 \--- xml-resolver:xml-resolver:1.2(*) - dependencies omitted (listed previously)BUILD SUCCESSFULTotal time: 1.38 secs |
Два плагина и пакет транзитивных зависимостей для gradle-nexus-staging-plugin благодаря http-builder (может быть, было бы неплохо заменить его на Jodd ?).
Резюме
Стоит уметь различать стандартные зависимости проектов и зависимости buildscript. Новая задача buildEnvironment помогает справиться с последним. Это, в свою очередь, становится необходимым, когда начинают появляться странные ошибки времени выполнения.
Протестировано с Gradle 2.10.
| Ссылка: | Уловки Gradle — покажите зависимости buildscript от нашего партнера JCG Марцина Заячковского в блоге Solid Soft . |