для чего нужен gradle

Gradle: Better Way To Build

Ни один проект с использованием платформы Java (и не только) не обходится без инструментов сборки (если только это не «Hello, world!»). Рано или поздно, но собирать дистрибутив руками надоедает. Да и компилировать из консоли было бы неплохо, если в проекте используется несколько разных IDE. А перед сборкой дистрибутива было бы здорово проставить номер версии в его имени. И unit тесты прогнать — не зря же Kent Beck книжки пишет. А там и Continues Integration на горизонте маячит. И здорово было бы научить CI сервер это все делать самостоятельно. Одним словом, есть уйма задач.

Раз есть задачи, то есть и решения. Думаю, большинство разработчиков хоть раз, но сталкивались с Ant. Очень многие используют Maven. Есть другие, не такие распространённые инструменты: GAnt, Buildr, и др. Каждый из них обладает набором своих плюсов и минусов, но сегодня я хочу представить вам кое-что новенькое. Gradle.

Gradle пытается объединить в себе все плюсы Ant, Maven и Ivy. И представить то, что получилось, с помощью Groovy. Теперь вместо того, чтобы скрещивать Batch-скрипты, java и xml-файлы конфигурации, можно просто написать несколько строчек кода на диалекте Groovy и радоваться жизни. Диалект специально разработан для описания сборки, тестирования, развертывания, экспорта и любых других действий над проектом, которые только могут прийти вам в голову.

Т.к. Gradle работает в запущеной JVM, он успешно использует библиотеки задач Ant, средства управления зависимостями Apache Ivy и другие существующие инструменты (TestNG, JUnit, Surefire, Emma, и т.п.). В принципе, несложно интегрировать в сборку любой инструмент, работающий в jvm. В придачу ко всему, диалект Groovy, используемый в Gradle, дает вам полную свободу действий. Совсем полную. Хотите условные выражения? Пожалуйста! Хотите циклы? Милости просим! Читать и писать файлы? Работать с сетью? Генерировать на лету собственные задачи? Все что угодно! И на нормальном, человеческом языке программирования, а не жутковатыми xml-конструкциями.

Интересная возможность: соответствующим образом настроенный Gradle-проект можно собрать на машине пользователя, на которой Gradle не установлен. Все, что требуется, — положить в дерево исходников 4 файла (которые Gradle сгенерирует для вас): 2 исполняемых для Win/*nix, 1 файл настроек и маленький jar. Всего на

20Kb. После этого проект можно собрать на любой машине, где есть доступ к Сети. Скрипт сам позаботится о скачивании правильной версии Gradle, о настройке и запуске сборки.

Миграция на Gradle очень проста. Например, сборку maven2 можно преобразовать в сборку Gradle автоматически (с сохранением настроенных зависимостей, артефактов, версий и подпроектов). И миграция уже началась. Сейчас этот инструмент используют проекты: Grails, Spring Security, Hibernate Core и даже GAnt (честно, GAnt собирается при помощи Gradle!).

Похвалили, теперь нужно продемонстрировать в действии.

Для начала создадим шаблонный java проект, чтобы продемонстрировать использование ‘build-by-convention’. А затем попытаемся его немного видоизменить, добавив в структуру файлов набор автоматизированных интеграционных тестов, чтобы показать, насколько большую свободу в использовании ‘convention’ предоставляет Gradle. В примере преднамеренно не упоминаются файлы исходников, т.к. не в них смысл.

Пусть у нас есть структура проекта (вы видели ее уже тысячу раз):

Создаем в каталоге project пустой файл build.gradle. Записываем туда одну строчку:

Запускаем команду gradle build и получаем:

>gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build

Total time: 4.116 secs

В консоли видим выполнение последовательности задач (Gradle Tasks), которые являются близким аналогом Ant Targets. В каталоге /project/build можно найти скомпилированные классы (в т.ч., аккуратно упакованные в jar), отчеты по выполнению тестов и другие результаты сборки.

Все это пока что ничем не отличается от того, к чему привыкли многочисленные участники проектов с использованием Maven. Те же каталоги, такой же pom.xml (только называется build.gradle). Но не спешите расчехлять тухлые помидоры и позвольте продемонстрировать одну из интересных возможностей Gradle.

Добавим интеграционные тесты. Создадим для них отдельную ветку каталогов:

и добавим в build.gradle следующий код:

Будут автоматически сформированы три новых task’a: компиляция (compileIntegTestJava), обработка ресурсов (processIntegTestResource) и объединяющая их integTestClasses. Попробуем запустить:

>gradle integTestClasses
:compileIntegTestJava
:processIntegTestResources
:integTestClasses

Total time: 1.675 secs

Ценой двух строчек мы получили 3 новых task’a и добавили в сборку проекта новый каталог. Но как только дело дойдет до написания этих тестов, мы обнаружим, что нам нужны все зависимости основного проекта, да еще и скомпилированные классы в придачу.
Не вопрос, пишем:

Наверное, при сборке нам пригодится JUnit. И неплохо было бы еще и запустить эти тесты. Опишем еще одну конфигурацию зависимостей.

Задачу для запуска тестов всё-таки пришлось написать. Впрочем, это было несложно: достаточно указать, откуда брать тесты и с каким classpath их запускать, т.е. «что». «Как» Gradle определит самостоятельно.

>gradle clean integrationTest
:clean
:compileJava
:processResources
:classes
:compileIntegTestJava
:processIntegTestResources UP-TO-DATE
:integTestClasses
:integrationTest

Total time: 4.195 secs

Обратите внимание, что Gradle обработал зависимость integTest.compileClasspath от main.classes и собрал source set main прежде, чем собирать интеграционные тесты!

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

О чем еще не сказано ни слова: о работе с task-ами, об инкрементальной сборке, о работе с подпроектами, о работе с Maven репозиториями, об интеграции с Ant, о стандартных plugin-ах, о init-scripts и многом-многом другом. Но об этом, быть может, в других статьях.

Источник

Gradle: 5 полезностей для разработчика

Привет, Хабр! Настало время, когда можно сказать, что «new build system» Gradle является стандартом отрасли Android-разработки. Инструмент сделан настолько просто и удобно, что большинство разработчиков не испытает трудностей, даже не зная, как он устроен, и какие дополнительные возможности в нём есть — возникающие проблемы легко решаются с помощью 5 минут на StackOverflow, путем копирования «магического кода» в конфигурационные файлы. Возможно, в том числе из-за этого не все разработчики изучают Gradle детально и не знают о многих его полезных возможностях, которые существенно облегчают жизнь.

1. Увеличиваем быстродействие

Время сборки напрямую влияет на скорость разработки. Тесты показывают, что каждая из версий, начиная с Gradle 2.0, становилась медленнее предыдущей. Однако затем разработчики исправились и хорошенько поработали над быстродействием в Gradle 2.4.

1. Поэтому первым делом следует убедиться, что вы используете актуальную версию Gradle 2.4+

3. После чего, проверив что модули вашего проекта не используют друг-друга как зависимости, тем самым создавая перекрёстные ссылки, можно смело включать режим параллельного выполнения, что также ускорит скорость сборки до

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

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

2. Расширяем BuildConfig

Как известно, файл конфигурации сборки (build.gradle) предоставляет возможность определить Product Flavors и Build Types, что даёт нам массу вариантов для разделения сборок по назначению. Например, “Сборка с тестовым сервером”, “Сборка с боевым сервером”, ”Сборка с логированием” и другие. Использование их для расширения BuildConfig (который генерируется каждый раз при сборке) даёт нам потрясающую гибкость. Например, удобное переключение между back-end-сервером, с которым работает наше приложение; включение/выключение определённого функционала – например, логи.

3. Используем переменные

Время не стоит на месте, а значит инструменты, библиотеки и Android имеют свойство обновляться. И если приложение развивается, то приходится открывать build.gradle и менять как минимум compileSdkVersion, buildToolsVersion, версии Android Support Library и Google Play Services. А если у нас в проекте используется много модулей или различные части библиотеки Google Play Services, это ведет к большому количеству мест изменений, и можно легко потерять время из-за опечатки в каком-то из файлов. Кроме того, возможно использование различных библиотек и инструментов в разных проектах, что плохо и может стать причиной проблем. Избежать подобной ситуации помогут gradle-переменные.

В самый верхний build.gradle добавляем

4. Выключаем Crashlytics

В большинстве случаев собирать аварийные завершения необходимо только в Release-сборках, которые мы выпускаем для пользователей/тестирования. Debug сборки разработчик использует для себя, и аварийные завершения будут видны ему в лог-файле, значит, дабы не засорять список реальных аварийных завершений у пользователей, необходимо выключить Crashlytics для Debug-сборок.
Задачу можно выполнить банальной проверкой типа сборки:

Но это не самое лучшее решение, т.к. плагин Fabric Gradle всё равно будет тратить время на генерацию и встраивание в ресурсы приложения уникального id сборки, чтобы Crashlytics back-end затем понял, какая сборка прислала данные. Поэтому применим более удобное решение, которое позволит ускорить время сборки debug-версии приложения.

После этого debug-сборки не будут получать id, и процесс сборки ускорится, но следует учитывать, что если разработчик попытается инициализировать в такой сборке Crashlytics, то приложение упадёт с выводом:

Т.е. обязательно оставьте проверку на тип сборки и используйте Crashlytics только для Release сборок или воспользуйтесь решением, приведённым в документации к Crashlytics на сайте Fabric:

5. Уменьшаем количество конфигураций ресурсов

В разрабатываемых нами приложениях мы часто используем сторонние библиотеки, например, Android Support Library, Google Play Services и другие. Многие из библиотек поставляются с различными внутренними ресурсами, которые в наших приложениях абсолютно не нужны. Например, Google Play Services поставляется с переводом на языки, которые ваше приложение не поддерживает. Вероятно, вы также не захотите поддерживать mdpi или tvdpi-разрешение в своём приложении.

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

При необходимости можно подойти более радикально и начать использовать multi-APK, тем более когда появился новый удобный механизм Splits.

Источник

Многомодульный Java-проект с Gradle. Шаг за шагом

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

Данная статья не будет подробно описывать такие темы, как плагины gradle (plugin), задачи (task), зависимости (dependencies), автоматическое тестирование и прочие прелести этого сборщика проектов. Во-первых, каждая тема заслуживает отдельной статьи или даже серии статей, а во-вторых, на эти темы уже есть статьи на хабре, например: Gradle: Tasks Are Code, Gradle: Better Way To Build. А еще на официальном сайте Gradle есть прекрасно написанный Gradle User Guide. Я же cфокусирую внимание на непосредственном решении поставленной задачи, и все сопутствующие темы будут описаны в рамках этой самой задачи.
Сначала определимся с целью, что же мы хотим получить на выходе? А цель указана в заголовке статьи. Мы хотим получить проект с несколькими модулями, который собирается с помощью Gradle. И так, приступим.

Шаг 1. Установка gradle

Примечение: Если выхотите просто “поиграть” с gradle, скачав файлы для статьи, или вам достались чужие исходники с волшебным файлом gradlew (gradlew.bat) в корне проекта, то устанавливать gradle не обязательно.

Gradle можно поставить, скачав последнюю версию со страницы загрузок Gradle или воспользовавшись менеджером пакетов в вашей любимой ОС (прим. Я ставил на Mac OS через brew и на Debian через apt-get из стандартных источников)

Результат первого шага:

Шаг 2. Пустой проект, плагины (plugin), обертка (wrapper)

Создадим папку проекта и в ее корне сделаем файл build.gradle со следующим содержимым:

Итоги второго шага (вывод сокращен):

Шаг 3. Заполняем пробелы

Для сравнения аналогичный блок в maven:

Итоги третьего шага:

Видно, что скачивается недостающая библиотека, и продемонстрировано ее использование.

Шаг 4. Достижение цели

Дополнение от MiniM: В gradle символ «:» используется вместо «/» и для более ветвистой структуры ссылки на проект могут выглядеть так «:loaders:xml-loader»

/main_project/build.gradle (блок dependencies )

Итог четвертого шага:

Шаг 5 (заключительный). Убираем мусор

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

На этом я закончу. Надеюсь, данная статья вызвала интерес у людей, не знакомых с 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 () с именем задачи, либо относительным путем, либо абсолютным путем.

Источник