что такое система сборки gradle

Крибле Крабле Gradle: магия автоматической сборки

Разработчики облегчают жизнь людям, а Gradle — разработчикам. Если вы пишете на Android, эта статья для вас. Читайте о том, что за зверь этот Gradle (спойлер: он слон), а также — как с ним работать.

Gradle — система автоматической сборки, которую используют для упрощения работы с Java. С помощью (условно) стандартизированных средств она помогает разработчикам собрать нужный продукт без потери его уникальности. Ведь процесс работы с Gradle — не просто выбор шаблона. Но обо всём по порядку.

Где скачать Gradle

Скачать Gradle можно на официальном сайте. Рекомендуем качать и устанавливать всё вручную (чтобы жизнь малиной не казалась). Инструкция, а также все необходимые ссылки даны в разделе Installing Gradle > Installing Manually. Кстати, рекомендуем прочитать всё. Вообще всё. Серьёзно.

Иногда выходит так, что во время определения система находит Gradle в неожиданном месте. На Windows это решается следующим образом:
for %i in (gradle.bat) do echo. %

Как работать с Gradle

Gradle не привязан к конкретной платформе. К тому же, в системе используют разные языки программирования. Наиболее популярные — Groovy DSL и Kotlin (но можно писать и на других). В статье будет использован первый вариант, так как это стандартный язык описания задач в Gradle.

Прежде чем начинать работу, обратите внимание на термины: «задача» и «плагин», ещё раз. Ведь именно на них строится вся работа с системой. Плагины предоставляют и создают задачи. Задачи — те действия, которые надо сделать. Всё очень просто.

Подробнее об этом вы можете прочитать в инструкции к плагинам: JavaCompile (добавить новые задачи), SourceSet (добавить новые объекты домена). Также плагины работают с соглашениями и расширяют объекты. Например, с помощью плагина можно добавить новые элементы DSL и (или) настроить их.

Набор «Core Plugins» автоматически создаётся при установке Gradle. На первых этапах рекомендуют использовать категорию «Utility», а именно — плагин «Build Init Plugin». Он предоставляет задачи для инициализации проекта в системе. Выбрать тип проекта можно из списка на сайте.

После этого в папке появятся новые файлы. В их числе:

В последнем файле будет отображена секция плагина. Этот плагин уже имеет прикреплённые к нему задачи. Их список можно посмотреть с помощью команды gradle tasks.

Задачи

Показаны блоками, по своим функциям. К каждой даётся краткое описание. Для понимания требуется знание английского на базовом уровне. Если вы не входите в эту группу — подойдёт любой переводчик. Сложных языковых конструкций в build.gradle нет.

После выбора задачи и её успешного завершения вы увидите внизу зелёную надпись «BUILD SUCCESSFUL». Это значит, что (вам повезло) всё прошло без проблем. Также внизу система выдаст краткий отчёт.

Если статус «executed» — задача действительно выполнена. Если «up-to-date» — нет. Это не значит, что произошёл какой-то сбой. В случае такого статуса задача не требует решения в принципе, т. е. её объект уже в актуальном состоянии.

Это произошло потому, что в Gradle автоматически формируется «Up-to-date checks» — инкрементальный билд, цель которого — оптимизация работы системы. Поэтому задачи, которые уже завершены или не требуют действий, не прорабатываются.

Зависимости

Управление зависимостями — указание библиотек или фреймворков, которые нужны проекту. Gradle должна включить эти зависимости в определённый момент, чтобы в конце собрать приложение корректно (или вообще). Команда gradle init для java-application в build-скрипте автоматически вызывает информацию о 2 конфигурациях.

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

Чтобы лучше понять зависимости и принцип работы с ними, прочтите главу «Managing Dependency Configurations» в официальной инструкции. Кстати, в «API and implementation separation» подробно объясняется про API и implementation, а также разницу между ними.

Если необходимо включить зависимость в итоговый артефакт, требуется указать всю необходимую для манифеста jar-файла информацию в настройках задачи jar. Как это сделать правильно, можете посмотреть, например, здесь.

Далее нужно включить в jar зависимости. Это необходимо для компиляции.
Слишком сложно? Используйте «Gradle Shadow Plugin».

Наиболее частые виды зависимостей:

Что из этого списка использовать, решает разработчик.
Для Java всё хорошо расписано в «Dependency management».

Лайфхаки

Несмотря на то, что Gradle — популярная и актуальная система автоматической сборки, проблемы в работе с ней возникают у многих. Вот несколько рекомендаций, которые могут значительно облегчить жизнь android-разработчику:

Используйте консоль. Найти команды иногда бывает проблематично, а при изменении build.gradle система может заглючить или, вообще, перезагрузить проект. Поэтому специалисты рекомендуют вызывать Gradle прямо из консоли.

Враппер обычно идёт вместе с проектом. На Linux и macOS можно обращаться напрямую. На Windows — вызывать вместо враппера bat-файл.

Gradle хранит кэш 1 сутки. Это можно перенастроить. Необходимо отредактировать код:

– –refresh-dependencies — полезная команда, которая запустит обновление всех зависимостей в Gradle. Может пригодиться, если какие-то данные в кэше повредились, так как верифицирует. Удобно использовать при повреждении данных кэша, так как происходит их верификация и обновление (если отличаются).

Используйте CI (непрерывную интеграцию) в работе с системой автоматической сборки. Пусть модульные тесты выполняются для всех коммитов. Также специалисты рекомендуют подключать и unit-тесты. Это можно сделать в Android Studio.

Такая комбинация позволит обнаружить ошибки раньше. И хотя она замедлит процесс запуска, разработчик сможет отдохнуть в дальнейшем. Так что лайфхак на перспективу.

Try again. Страшно? (Нам тоже) На самом деле синхронизацию не всегда нужно сразу запускать заново. Сначала специалисты рекомендуют проверить систему в целом. Например, с помощью любой простой команды — это поможет понять, каковы шансы на успех следующей синхронизации.

Настройте с Gradle среду разработки IntelliJ IDEA. Это позволит оптимизировать процесс работы, а также воспользоваться волшебным списком.

Совет для тех, кто работает с Gradle из командной строки Android Studio. Проверьтесь на ошибку «Starting a Gradle Daemon, 1 incompatible could not be reused» (#68374709). Это бич системы, который разработчики пока не исправили.

Одна из основных проблем Gradle — «Gradle build failed». Обойдёмся без лишних слов, если вам это уже знакомо. Если же нет — удачи.

Впрочем, главная проблема Gradle другая. Время, которое требуется системе на сборку, уже давно стало (очень печальной) легендой в кругах специалистов. Ускорить работу нельзя, по крайней мере — значительно.

Так что придётся ждать в любом случае.

Можете, например, слетать куда-нибудь в космос, как в «Интерстеллар».

Вывод

Gradle — это хорошее решение, несмотря на все минусы. Автоматическая сборка позволит вам сэкономить силы и время (как иронично это бы ни звучало после предыдущего абзаца). А также — сделать своё приложение чище. Система заметит любую ошибку и не позволит закончить работу, пока та не будет исправлена (любой ценой).

Источник

Gradle — Краткое руководство

«Gradle — система автоматизации сборки с открытым исходным кодом»

Ant и Maven достигли значительных успехов на рынке JAVA. Ant был первым инструментом сборки, выпущенным в 2000 году, и он разработан на основе идеи процедурного программирования. Позже он улучшен благодаря возможности принимать плагины и управление зависимостями по сети с помощью Apache-IVY. Основным недостатком является XML как формат для написания сценариев сборки, поскольку иерархическая структура не подходит для процедурного программирования, а XML имеет тенденцию становиться неуправляемо большим.

Maven представлен в 2004 году. Он значительно улучшен по сравнению с ANT. Он меняет свою структуру и продолжает использовать XML для написания спецификаций сборки. Maven опирается на соглашения и может загружать зависимости по сети. Основным преимуществом maven является его жизненный цикл. Следуя одному и тому же жизненному циклу для нескольких проектов непрерывно. Это связано с гибкостью. Maven также сталкивается с некоторыми проблемами в управлении зависимостями. Он плохо обрабатывает конфликты между версиями одной и той же библиотеки, и сложные настраиваемые сценарии сборки на самом деле труднее писать в maven, чем в ANT.

Наконец, в 2012 году появился Gradle. Gradle обладает некоторыми эффективными функциями обоих инструментов.

Особенности Gradle

Ниже приведен список функций, которые предоставляет Gradle.

Декларативные сборки и сборка по соглашению — Gradle доступен с отдельным предметно-ориентированным языком (DSL) на основе языка Groovy. Gradle предоставляет элементы декларативного языка. Эти элементы также обеспечивают поддержку сборки по соглашению для Java, Groovy, OSGI, Web и Scala.

Структурируйте свою сборку — Gradle наконец-то позволяет вам применять общие принципы проектирования к вашей сборке. Это даст вам идеальную структуру для сборки, так что вы сможете разработать хорошо структурированную и легко поддерживаемую, понятную сборку.

Глубокий API — Используя этот API, он позволяет вам отслеживать и настраивать его конфигурацию и поведение при выполнении.

Масштабирование Gradle — Gradle может легко увеличить свою производительность, от простых сборок одного проекта до огромных многопроектных сборок предприятия.

Многопроектные сборки — Gradle поддерживает многопроектные сборки и поддерживает частичные сборки. Если вы строите подпроект, Gradle позаботится о создании всех подпроектов, от которых он зависит.

Различные способы управления вашими сборками — Gradle поддерживает различные стратегии для управления вашими зависимостями.

Gradle — это первый инструмент интеграции сборки — Gradle полностью поддерживается для задач ANT, инфраструктура репозитория Maven и lvy для публикации и получения зависимостей. Gradle также предоставляет конвертер для превращения Maven pom.xml в скрипт Gradle.

Легкость миграции — Gradle может легко адаптироваться к любой вашей структуре. Поэтому вы всегда можете разработать свою сборку Gradle в той же ветке, где вы можете создать живой скрипт.

Gradle Wrapper — Gradle Wrapper позволяет выполнять сборки Gradle на машинах, где Gradle не установлен. Это полезно для непрерывной интеграции серверов.

Бесплатный открытый исходный код — Gradle — это проект с открытым исходным кодом, который распространяется под лицензией Apache Software License (ASL).

Groovy — скрипт сборки Gradle написан на Groovy. Весь дизайн Gradle ориентирован на использование в качестве языка, а не жесткой структуры. А Groovy позволяет вам написать собственный скрипт с некоторыми абстракциями. Весь API Gradle полностью разработан на языке Groovy.

Декларативные сборки и сборка по соглашению — Gradle доступен с отдельным предметно-ориентированным языком (DSL) на основе языка Groovy. Gradle предоставляет элементы декларативного языка. Эти элементы также обеспечивают поддержку сборки по соглашению для Java, Groovy, OSGI, Web и Scala.

Структурируйте свою сборку — Gradle наконец-то позволяет вам применять общие принципы проектирования к вашей сборке. Это даст вам идеальную структуру для сборки, так что вы сможете разработать хорошо структурированную и легко поддерживаемую, понятную сборку.

Глубокий API — Используя этот API, он позволяет вам отслеживать и настраивать его конфигурацию и поведение при выполнении.

Масштабирование Gradle — Gradle может легко увеличить свою производительность, от простых сборок одного проекта до огромных многопроектных сборок предприятия.

Многопроектные сборки — Gradle поддерживает многопроектные сборки и поддерживает частичные сборки. Если вы строите подпроект, Gradle позаботится о создании всех подпроектов, от которых он зависит.

Различные способы управления вашими сборками — Gradle поддерживает различные стратегии для управления вашими зависимостями.

Gradle — это первый инструмент интеграции сборки — Gradle полностью поддерживается для задач ANT, инфраструктура репозитория Maven и lvy для публикации и получения зависимостей. Gradle также предоставляет конвертер для превращения Maven pom.xml в скрипт Gradle.

Легкость миграции — Gradle может легко адаптироваться к любой вашей структуре. Поэтому вы всегда можете разработать свою сборку Gradle в той же ветке, где вы можете создать живой скрипт.

Gradle Wrapper — Gradle Wrapper позволяет выполнять сборки Gradle на машинах, где Gradle не установлен. Это полезно для непрерывной интеграции серверов.

Бесплатный открытый исходный код — Gradle — это проект с открытым исходным кодом, который распространяется под лицензией Apache Software License (ASL).

Groovy — скрипт сборки Gradle написан на Groovy. Весь дизайн Gradle ориентирован на использование в качестве языка, а не жесткой структуры. А Groovy позволяет вам написать собственный скрипт с некоторыми абстракциями. Весь API Gradle полностью разработан на языке Groovy.

Почему Groovy?

Полный API Gradle разработан с использованием языка Groovy. Это преимущество внутреннего DSL над XML. Gradle — это универсальный инструмент для сборки; основное внимание уделяется Java-проектам. В таких проектах члены команды будут очень хорошо знакомы с Java, и лучше, чтобы сборка была максимально прозрачной для всех членов команды.

Такие языки, как Python, Groovy или Ruby, лучше подходят для сборки фреймворка. Почему Groovy был выбран, так это потому, что он предлагает наибольшую прозрачность для людей, использующих Java. Базовый синтаксис Groovy такой же, как Java. Groovy предлагает гораздо больше.

Gradle — Установка

Gradle — это инструмент для сборки, основанный на Java. Есть некоторые предварительные условия, которые должны быть установлены перед установкой рамы Gradle.

Предпосылки

JDK и Groovy являются необходимыми условиями для установки Gradle.

Gradle требует JDK версии 6 или более поздней версии для установки в вашей системе. Он использует библиотеки JDK, которые установлены и установлены в переменную окружения JAVA_HOME.

Gradle содержит собственную библиотеку Groovy, поэтому нам не нужно явно устанавливать Groovy. Если он установлен, Gradle игнорирует его.

Gradle требует JDK версии 6 или более поздней версии для установки в вашей системе. Он использует библиотеки JDK, которые установлены и установлены в переменную окружения JAVA_HOME.

Gradle содержит собственную библиотеку Groovy, поэтому нам не нужно явно устанавливать Groovy. Если он установлен, Gradle игнорирует его.

Ниже приведены инструкции по установке Gradle в вашей системе.

Шаг 1 — Проверьте установку JAVA

Прежде всего, вам необходимо установить Java Software Development Kit (SDK) в вашей системе. Чтобы убедиться в этом, выполните команду Java –version на любой платформе, с которой вы работаете.

В винде —

Выполните следующую команду, чтобы проверить установку Java. Я установил JDK 1.8 в моей системе.

В Linux —

Выполните следующую команду, чтобы проверить установку Java. Я установил JDK 1.8 в моей системе.

Мы предполагаем, что читатели этого руководства установили Java SDK версии 1.8.0_66 в своей системе.

Шаг 2 — Загрузите файл сборки Gradle

Шаг 3 — Настройка среды для Gradle

Этот шаг зависит от платформы.

В винде —

Извлеките загруженный zip-файл с именем gradle-2.11-all.zip и скопируйте дистрибутивные файлы из каталога Downloads \ gradle-2.11 \ в C: \ gradle \ location.

В Linux —

Вы можете использовать следующее, чтобы переместить дистрибутивные файлы из Downloads / gradle-2.11 / в / opt / gradle / location. Выполните эту операцию из каталога загрузок.

Выполните следующую команду, чтобы выполнить файл

Шаг 4: Проверьте установку Gradle

В окнах:

Вы можете выполнить следующую команду в командной строке.

Вывод: там вы найдете версию Gradle.

В Linux:

Вы можете выполнить следующую команду в терминале.

Вывод: там вы найдете версию Gradle.

Gradle — Build Script

Gradle использует Groovy для написания скриптов.

Написание сценария сборки

Gradle предоставляет предметно-ориентированный язык (DSL) для описания сборок. Это использует язык Groovy, чтобы упростить описание сборки. Каждый сценарий сборки Gradle кодируется с использованием UTF-8, сохраняется в автономном режиме и называется build.gradle.

build.gradle

Выполните следующую команду в командной строке. Он выполняет вышеуказанный скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Если вы думаете, что задача работает аналогично цели ANT, то это правильно — задача Gradle эквивалентна цели ANT.

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

Сценарий Grade в основном использовал два реальных объекта, один из них — объект проекта, а другой — объект сценария.

Объект проекта — каждый сценарий описывает один или несколько проектов. Во время выполнения этот сценарий настраивает объект проекта. Вы можете вызывать некоторые методы и использовать свойства в вашем скрипте сборки, которые делегированы объекту проекта.

Сценарий Объект — Gradle взят код сценария в классы, который реализует интерфейс сценариев, а затем выполняется. Это означает, что все свойства и методы, объявленные интерфейсом скрипта, доступны в вашем скрипте.

Groovy Основы

Скрипты сборки Gradle используют полнофункциональный Groovy API. В качестве стартапа взгляните на следующие примеры.

В следующем примере объясняется, как преобразовать строку в верхний регистр.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

В следующем примере объясняется, как печатать значение неявного параметра ($ it) 4 раза.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Groovy язык предоставляет множество функций, некоторые из которых обсуждаются ниже.

Groovy JDK Методы

Groovy добавляет множество полезных методов в стандартные классы Java. Например, Iterable API из JDK реализует метод each (), который выполняет итерацию по элементам Iterable Interface.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Средства доступа к недвижимости

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

Необязательные скобки при вызове метода

Groovy содержит специальную функцию в вызове методов, которая является необязательной скобкой для вызова метода. Эта функция также применима к сценариям Gradle.

Посмотрите на следующий синтаксис. Это определяет метод, вызывающий systemProperty тестового объекта.

Закрытие как последний параметр метода

Gradle DSL использует замыкания во многих местах. Если последний параметр метода является закрытием, вы можете поместить закрытие после вызова метода.

Следующий фрагмент кода определяет синтаксис, используемый Closures в качестве параметров метода repositories ().

Импорт по умолчанию

Gradle автоматически добавляет набор операторов импорта в сценарии Gradle. В следующем списке показаны пакеты импорта по умолчанию для скрипта Gradle.

Ниже приведены стандартные пакеты импорта в скрипт Gradle.

Gradle — Задачи

Скрипт сборки Gradle описывает один или несколько проектов. Каждый проект состоит из разных задач. Задача — это часть работы, которую выполняет сборка. Задачей может быть компиляция некоторых классов, хранение файлов классов в отдельной целевой папке, создание JAR, генерация Javadoc или публикация некоторых достижений в репозитории.

В этой главе объясняется, что такое задача, а также как ее создать и выполнить.

Определение задач

Выполните следующую команду в командной строке. Он выполняет вышеуказанный скрипт. Вы должны выполнить это там, где хранится файл build.gradle.

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

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Вы также можете использовать строки для имен задач. Взгляните на тот же самый привет пример. Здесь мы будем использовать String как задачу.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Вы также можете использовать альтернативный синтаксис для определения задачи. Это использует метод create () для определения задачи. Взгляните на тот же самый привет пример, приведенный ниже.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Поиск задач

Если вы хотите найти задачи, которые вы определили в файле сборки, вам нужно использовать соответствующие стандартные свойства проекта. Это означает, что каждая задача доступна как свойство проекта, используя имя задачи в качестве имени свойства.

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

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Вы также можете использовать все свойства через коллекцию задач.

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

Вы также можете получить доступ к пути задачи, используя задачи. Для этого вы можете вызвать метод getByPath () с именем задачи, либо относительным путем, либо абсолютным путем.

Источник

Готовьсь, цельсь, пли! Как не обжечься при сборке Gradle-приложения, и настолько ли всё серьезно?

Доброго дня, читатель! Меня зовут Стручков Михаил и я Android-разработчик в команде мобильного оператора Yota.

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

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

Очень сложно рассмотреть всю работу с Gradle в одной статье, поэтому планирую последовательно пополнять список:

Готовьсь, цельсь, пли! Как не обжечься при сборке Gradle-приложения, и настолько ли всё серьезно?

Для удобства навигации по статье, ниже представлено оглавление:

Gradle приобрел широкую популярность в качестве системы сборки не только JVM-приложений. Широта предоставляемого инструментария, возможности его адаптации под кастомные задачи, возможности для сборки крупных проектов, простота интеграции с различными CI-системами делают свое дело.

Структура проекта

Итак, главная сущность в мире Gradle – это Project. Project-ом выступает само наше приложение, которое мы только что создали. У project-а могут быть subproject-ы, у subproject-а могут быть свои subproject-ы, и таким образом получается древовидная структура. Хорошей практикой является подход, при котором степень вложенности не превышает двух. Такая структура подходит для большинства проектов. При этом subproject-ы можно просто называть Gradle-модулями.

Если вы пользуетесь IDE от JetBrains или Android Studio, по умолчанию они не дадут вам создать иерархию больше двух (для стандартных проектов), что уже наталкивает на мысль, что так делать не стоит.

Project узнаёт обо всех своих subproject из файла конфигурации settings.gradle (.kts). Написанный здесь скрипт будет выполняться на этапе инициализации проекта.

Инициализация

Итак, в settings.gradle (.kts) мы определяем содержимое нашего приложения, и учим Gradle к нему подступаться. В самом начале задаем имя нашего проекта:

Теперь мы можем легко его получить из любого subproject-а на последующих этапах.

Конфигурация плагинов

Внутри блока plugins есть возможность указать дефолтную версию для плагина, если не используется никакая другая. При этом эту версию можно брать извне, например, из gradle.properties:

Готово! Теперь можно добавить зависимость Android Gradle Plugin в classpath (о котором чуть позже) и затем успешно подключать Android-плагины в билдскриптах.

В блоке resolutionStrategy мы можем определить правила для подключения плагинов, используемых проекте. На коде ниже приведен пример того, как можно хитрым образом динамически подключить Android Gradle Plugin на тот случай, если в проекте он начнёт использоваться:

После такого финта ушами, AGP автоматически подключится в classpath по необходимости. Здесь в поле requested находится реквест плагина, который мы явно сформировали:

Чтобы узнать, что будет запрошено в конечном итоге, следует использовать поле target.

Важный момент: версию плагинов в явном виде стоит определять именно в рутовом build.gradle (.kts). Если сделать это как-то по-другому, чаще всего будет появляться следующее:

Полный зоопарк. Я не буду загружать подробностями (ибо у автора тоже с них взрывается мозг), но суть такова, что рутовый build.gradle (.kts) является для этого централизованным местом.

Подключение Gradle-проектов и композитная сборка

Далее с помощью include объявляем существующие в нашем проекте подпроекты (они же по-простому gradle-модули). При этом, если модуль лежит где-то в другом месте и вообще он гриб, можно явно указать, как и где его найти с помощью project:

И последнее, но не менее интересное – includeBuild. С помощью него можно определить проект, который мы бы хотели собрать, и определить интерфейс до сборки основного проекта. Таким образом, имеем возможность организовать композитную сборку:

C помощью лямбды в dependencySubstitution можно подменить зависимости, используемые в includeBuild-проекте, в том числе на те, что предоставляет наш проект, как на примере выше.

Где можно использовать композитную сборку?

Из своего опыта могу сказать, что композитная сборка может быть очень полезна, когда мы хотим отдебажить какой-нибудь Gradle-проект из другого репозитория. Например, это может быть наш собственный Gradle-плагин. Для этого просто выбираем Debug у Gradle-задачи из нашего плагина, который мы подключаем через композитную сборку:

После этого можно пользоваться всеми радостями отладки от IDE: ставить брейкпоинты, просматривать значения переменных и т.д. при выполнении кода Gradle-плагина.

P.S. Отладить таким образом можно не только Gradle-плагин, но и все содержимое build.gradle (kts), и в том числе на Groovy! Где ещё может пригодиться композитная сборка, поговорим немного дальше по ходу статьи.

Также settings.gradle (.kts) может с успехом отсутствовать. В этом случае Gradle поймёт, что других модулей проекте нет, и на этом успокоится.

Многие уже привыкли видеть settings.gradle (.kts) как скрипт, где только перечислены все известные в приложении Gradle-проекты. По опыту починки различных поломок с Gradle могу сказать, что сюда посмотрят в последнюю очередь. Если есть возможность не дописывать сложную логику сюда, лучше этого не делать. В большинстве случаев эту логику можно реализовать в build.gradle (.kts) рутового Gradle-проекта, что будет более очевидно для других разработчиков.

После выполнения инициализации Gradle создает объекты типа Project, с которыми мы продолжаем работу уже на этапе конфигурации.

Конфигурация

Также известна под именами “Sync Project With Gradle Files”, “Load Gradle Changes”, “Reload All Gradle Projects”. На данном этапе главными игроками выступают билдскрипты build.gradle (.kts).

Резолвятся и загружаются зависимости для каждого из известного в settings.gradle (.kts) Gradle-проекта;

Строится граф выполнения Gradle-задач для этапа сборки;

Определяются переменные и конфигурируются данные для выполнения задач на этапе сборки.

О подкапотном пространстве 2 и 3 этапов предлагаю поговорить в статье про Gradle-задачи и в комментариях, а сейчас давайте немного сосредоточимся на том, как быть с зависимостями.

Управление зависимостями

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

При поиске зависимостей Gradle осуществляет поиск по репозиториям в том порядке, в котором мы эти репозитории у себя объявили. Из этого вытекает, что репозитории с максимальным числом зависимостей стоит выносить в самый верх, и в целом стараться держать как можно меньше репозиториев.

В блоке buildscript определяются зависимости, которые необходимо загрузить и положить в classpath для их доступности на этапе конфигурации:

Для подключения зависимостей на этапе сборки, блоки dependencies и repositories добавляются в корень билдскрипта build.gradle (.kts). В качестве зависимостей могут быть как другие gradle-проекты, так и внешние/локальные библиотеки:

Для подключения Gradle-проектов используется символ “:”. С его помощью мы определяем путь, по которому лежит подключаемый Gradle-проект относительно рутового Gradle-проекта.

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

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

Типы зависимостей

При подключении зависимостей в compileClasspath, мы получим runtime exception при попытке достучаться до кода зависимости во время выполнения, поскольку зависимость не попала в приложение. Но в то же время код зависимости будет доступен на этапе сборки проекта. Подключая зависимости в runtimeClasspath, мы гарантируем их попадание в приложение, а значит, и безопасность выполнения кода в runtime. Здесь-то и приходит понимание, что implementation и api добавляют зависимости в оба classpath-а. При этом api также позволяет получить доступ к коду gradle-проекта в случае его транзитивного подключения.

В качестве apiElements и runtimeElements на рисунке обозначен код, который мы хотим отдать на использование в другие gradle-модули.

Производительность конфигурации

Gradle старается, насколько это возможно, оптимизировать процесс конфигурации. Наша задача этому не мешать, а именно, стараться не взаимодействовать с другими gradle-проектами на этапе конфигурации напрямую. Это приводит к связности проектов и замедляет скорость конфигурации.

Такие блоки можно определить в root-проекте, поскольку он и так неявно связан со всеми подпроектами. Но стоит помнить, что выполнение подобного трюка в дочернем проекте оставит негативный след на скорости конфигурации. Если потребность всё же есть, лучше сделать зависимость между Gradle-задачами на этапе сборки.

Как сделать задачу для этапа конфигурации?

Почему не следует использовать dependsOn

Связывая задачи таким образом, мы должны быть уверены в том, что, как и когда выполняет Gradle-задача, от которой мы хотим зависеть. Нет никаких гарантий, что при её изменении наш код не сломается.

Чтобы избежать подобных проблем, задачи следует связывать с помощью их inputs и outputs. В этом случае в качестве бонуса мы получим еще и инкрементальность (aka up-to-date проверки), что значительно снизит время повторной сборки. Чтобы во всем разобраться, можно посмотреть доклад Степана Гончарова (таймкод) и пример из документации.

Немного о buildSrc

Еще одна вещь, о которой я не могу не упомянуть, это buildSrc. Модуль buildSrc собирается каждый раз перед конфигурацией нашего рутового проекта и поставляется на этап конфигурации в виде jar. Его довольно удобно использовать для объявления зависимостей, а также содержать общую логику для билдскриптов. Подробнее о том, как использовать buildSrc в Gradle-проекте хорошо описано в этой статье.

P.S. Сейчас в нашем проекте несколько десятков модулей и сложно сказать, что проблема buildSrc ощутимо по нам ударила. Но я не исключаю, что в относительно близкое время композитный билд действительно станет нашим будущим.

Куда еще можно вынести общую логику билдскриптов?

Если вы используете Groovy, можно вынести логику в отдельный билдскрипт и подключать его в нужные места вот так:

При этом скрипт можно положить напрямую в папку с проектом. Поскольку Groovy интерпретируемый язык, то ничего заранее компилировать не придется.

Если вы пишете подключаемые билдскрипты на Kotlin DSL, то они обязательно должны лежать в buildSrc. Связано это с тем, что Kotlin-скрипт должен быть скомпилирован перед использованием. При этом для подключения нужно выполнить небольшой финт ушами и в build.gradle (.kts) модуля buildSrc добавить следующее:

Теперь можем добавить Kotlin-скрипт в buildSrc/src/main/kotlin (java):

И подключить его вот так:

Скрипт, подключаемый таким образом, компилируется всего один раз перед использованием, что не повлияет на скорость конфигурации, и даже ускорит её, если вынести достаточно жирный кусочек. Однако в buildSrc при этом будет сгенерировано приличное количество кода.

Для того, чтобы связать Kotlin и Groovy, в Kotlin-скрипты можно подключать стандартные *.gradle с помощью того же apply:

Сборка

Вот мы и плавно подобрались к тому, что чаще всего поджигает наш ноутбук рождает приложение на свет. На этом этапе Gradle начинает выполнять задачи, которые были добавлены в граф зависимости на этапе конфигурации в нужном порядке.

Коротко про Gradle Task

Gradle Task представляет собой единицу работы, которую выполняет сборка. К примеру, это может быть компиляция классов, создание JAR, создание документации Javadoc или публикация в репозиторий.

Задаче очень желательно добавлять description и group, чтобы без лишних телодвижений было понятно, чем она занимается. После добавления group задачу будет удобно искать и запускать:

Задачу можно выполнить также и через консоль с помощью команды:

Gradle Daemon

Несколько советов по оптимизации скорости сборки

Параллельное выполнение тасок.

Обновление Gradle.

Gradle важно периодически обновлять. Связано это с тем, что с каждой версией в Gradle привносят улучшения по скорости сборки, исправления багов и новые интересные плюшки. Для удобства обновления, был придуман Gradle Wrapper (или просто Wrapper). Это ни что иное, как обычная Gradle-задача. Теперь для обновления версии можно написать в рутовом build.gradle (.kts) следующее:

, где вместо gradle_version указываем желаемую версию Gradle. Тем самым Gradle сам загрузит нужную версию и положит её в папку с проектом. Она же будет использоваться в дальнейшем по умолчанию, а счастливые мы сможем запускать задачи с помощью скрипта gradlew, который появится в папке с нашим проектом.

Правильное использование api/implementation.

При изменении реализации зависимости Gradle пересобирает «на холодную» все зависящие от неё модули. Я уже упомянул про api и implementation в разговоре о способах подключения зависимостей, и теперь понятно, что при подключении зависимости через api, она также транзитивно попадает в classpath-ы модулей, в которые мы подключили наш модуль. Тем самым увеличивается количество модулей, которые gradle будет пересобирать при изменении зависимости. Если нет необходимости в транзитивном использовании кода из зависимости, для её подключения следует использовать implementation.

Инкрементальность и build-кеш.

UP-TO-DATE. Возникает в случае, если разработчик задачи позаботился о ней и самостоятельно реализовал инкрементальность её выполнения (проверки на up-to-date), или же все зависимости этой задачи, если они есть, были успешно взяты из кеша, или признаны гредлом up-to-date.

FROM-CACHE. Это состояние возникает в случае, если Gradle смог восстановить outputs задачи из билд-кеша. При этом по умолчанию build-cache выключен. Build-cache довольно удобно использовать на CI, таким образом ускорив выполнение пайплайнов Gradle-сборки. Как организовать build-cache всегда можно узнать тут.

При использовании билд-кеша в локальных сборках, знаменитый Clean/Rebuild теряет свою магическую силу, поскольку параметры для задач всегда будут тянуться из Gradle-кеша. Однако для больших проектов отсутствие кеша может быть проблемой, поскольку время сборки «на холодную» способно занимать несколько десятков минут. Если это ваш случай, и вы сталкивались с проблемами инвалидации кеша, напишите в комментариях.

Бонус для дочитавших до конца: Gradle-плагин

Источник