Gradle - Что где валяется и когда всё соберётся

Что такого есть в Gradle, что вам стоит перейти на него? Какие возможности этой системы сборки наиболее интересны в больших проектах, и как эффективно её применять? Обо всем этом и многом другом пойдет речь в рамках данного доклада. Мы рассмотрим использование стандартных плагинов и задач, заглянем под капот системы зависимостей и поймем, что вытворяет Gradle с вашим компьютером во время сборки. В практической части поговорим о параллельных и инкрементальных сборках, а также напишем плагин и пару задач, которые будут работать максимально эффективно. Ну и напоследок, вы научитесь отлаживать Gradle скрипты и плагины, чтобы быстро решать проблемы со сборкой.

Transcript

1. Gradle Что где валяется и когда всё соберётся YURIY ARTAMONOV CUBA PLATFORM
2. Императивный подход: Ant <target name=“compile”> <mkdir dir=“${build.dir}”/> <javac srcdir=“${src.dir}” destdir=“classes.dir”/> </target>
3. Декларативный подход: Maven <build> <sourceDirectory>src</sourceDirectory/> <plugins> ... </plugins> </build>
4. 2011 год. Остаться на Ant или перейти на Maven? Переходим на Gradle 1.0 Milestone 6!
5. Система сборки Gradle Сборка описывается файлом build.gradle (+ settings.gradle) Файл сборки – код на Groovy (+ DSL) Проект и его сборку можно описать декларативно Для сборки можно подключать плагины (сборка WAR, запуск Jetty, etc)
6. Задачи в Gradle Единица исполнения – задача Каждая задача – это Groovy объект Задачи связаны между собой особым порядком исполнения и зависимостями Задачи включают в себя несколько действий
7. Встроенные типы задач В Gradle много встроенных типов задач: Copy, Jar, Zip, JavaExec.
8. Плагины Gradle
9. Gradle – это Maven, только лучше Gradle может использовать зависимости из Maven репозиториев Gradle может генерировать pom.xml для собранных артефактов Gradle расширяет модель зависимостей Maven, добавляя концепцию конфигураций См. https://gradle.org/maven_vs_gradle/, - Gradle лучше чем Maven. - Чем? - Чем Maven.
10. Где и что создаётся при сборке? ~/.gradle ./.gradle <module>/build
11. Файлы проекта
12. Непрраааввильно ты, Дядя Фёдор, билд собираешь! 1. Всегда используйте daemon (включен в 3.1 по умолчанию) > gradle --daemon 2. Используйте аббревиатуры задач: > gradle asse buildWS dep 3. Компилируйте только нужные проекты: > gradle :app-web:deploy start 4. Очищайте только нужные проекты: > gradle :app-core:clean 5. Используйте --offline если в вашем проекте есть –SNAPSHOT зависимости
13. Доколе?
14. Параллельные сборки Режим --parallel позволяет сэкономить время в проектах с большим количеством независимых модулей или несколькими очень большими независимыми модулями. > gradle coJava --parallel Как не накосячить: 1) У всех задач должны быть зависимости 2) У некоторых задач, должен быть определён порядок: start.mustRunAfter deploy
15. Инкрементальные сборки Задача может проделывать работу над только что изменившимися файлами, не переделывая свою работу над теми файлами, которые не менялись. Incremental Задача должна : определять входные файлы, входные параметры и выходные файлы принимать объект IncrementalTaskInputs реализовать логику реакции на изменённые и удалённые файлы https://github.com/jreznot/gd-incremental
16. И не таких дебажили! Отлаживать скрипты нельзя  Можно отлаживать задачи, плагин buildSrc, отдельные проекты плагинов Для отладки нужны опции GRADLE_OPTS и gradle должен быть запущен с --no-daemon Если вам придётся разбираться с проблемой в задаче, объявленной в скрипте, то воспользуйтесь опциями --debug --no-daemon
17. Параметры отладки > set GRADLE_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006 > gradle -Porg.gradle.debug=true --no-daemon cssPack Listening for transport dt_socket at address: 5006
18. Groovy то у нас есть, У нас ума не хватает! Соблюдайте баланс между декларативным и императивным подходами: 1) Выносите переиспользуемый код в плагин проекта в buildSrc 2) Если одинаковый код используется в нескольких проектах, то публикуйте плагин и используйте его в проектах 3) Если задача становится типовой для проектов – делайте декларативные настройки
19. Откуда берутся зависимости Плагины берутся из репозиториев, объявленных в buildScript { repositories { Артефакты Maven для компиляции скачиваются из репозиториев, объявленных в repositories { Артефакты Maven попадают в компиляцию модуля если они объявлены в dependencies { модуля А ещё… Репозитории мог добавить плагин Зависимости мог добавить плагин Зависимости могла добавить задача во время этапа конфигурации Репозиторий mavenLocal(~/.m2) обычно имеет приоритет над удалёнными репозиториями
20. Какие зависимости? Используйте --refresh-dependencies на серверах CI Загляните в ~/.m2, возможно кто-то или что-то установило туда другую версию артефакта Знайте, какие репозитории добавляют плагины! Используйте задачу dependencies нужного модуля для расшифровки разрешения зависимостей Если ничего не помогло, то открывайте ~/.gradle/caches/modules-2/
21. BUILD SUCCESSFUL