Для чего нужен gradle
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.
Gradle в сравнении с Maven: Производительность, совместимость, сборка и многое другое
Gradle — один из нескольких инструментов разработки Java, представленных во всеобщем руководстве разработчика Java от Stackify, но это не единственный инструмент автоматизации сборки, который следует рассмотреть. Maven — более старая и часто используемая альтернатива, но какая система сборки лучше всего подходит для вашего проекта? Поскольку другие инструменты, такие как Spring, позволяют разработчикам выбирать между этими двумя системами, в сочетании с растущим числом интеграций для обеих, решение в значительной степени зависит от вас.
Размер вашего проекта, потребность в кастомизации и некоторые другие переменные могут помочь вам сделать выбор. Давайте посмотрим.
Что такое Gradle?
Gradle — это система автоматизации сборки, которая является полностью открытым исходным кодом и использует концепции, которые вы видите в Apache Maven и Apache Ant. Она использует специфический язык, основанный на языке программирования Groovy, что отличает ее от Apache Maven, который использует XML для конфигурации проекта. Она также определяет порядок выполнения задач с помощью направленного ациклического графа.
Несколько разработчиков создали Gradle и впервые выпустили его в 2007 году, а в 2013 году он был принят компанией Google в качестве системы сборки для проектов Android. Она была разработана для поддержки многопроектных больших сборок. Она также позволяет дополнять вашу сборку, поскольку знает, какие части вашего проекта обновляются. Задачи, которые зависят от обновленных частей повторно не выполняются. На данный момент последним стабильным релизом является версия 3.4, которая была выпущена в феврале 2017 года. Она поддерживает разработку и последующее развертывание с использованием Java, Scala и Groovy, а в будущем будут представлены другие рабочие процессы и языки.
Что такое Maven?
Maven используется для автоматизации сборки проектов с использованием Java. Он помогает составить схему сборки конкретного программного обеспечения, а также его различных зависимостей. Он использует XML-файл для описания проекта, который вы собираете, зависимостей программного обеспечения от сторонних модулей и частей, порядка сборки, а также необходимых плагинов. Существуют заранее определенные цели для таких задач, как упаковка и компиляция.
Maven загружает библиотеки и плагины из различных репозиториев, а затем помещает их все в кэш на вашей локальной машине. Хотя Maven преимущественно используется для проектов на Java, вы можете использовать его для Scala, Ruby и C#, а также для множества других языков.
Gradle в сравнении с Maven
Существуют некоторые фундаментальные различия в подходе этих двух систем к сборке. Gradle основан на графе зависимостей задач, в котором задачи — это то, что выполняет работу, в то время как Maven основан на фиксированной и линейной модели фаз. В Maven цели привязываются к фазам проекта, и цели выполняют ту же функцию, что и задачи в Gradle, являясь «элементами, которые выполняют работу».
С точки зрения производительности, обе программы позволяют параллельно выполнять многомодульные сборки. Однако Gradle позволяет выполнять инкрементные сборки, поскольку проверяет, какие задачи обновлены, а какие нет. Если это так, то задача не выполняется, что дает вам гораздо меньшее время сборки. Другие отличительные особенности производительности, которые можно найти в Gradle, включают:
Инкрементная компиляция для классов Java
Избегание компиляции для Java
Использование API для инкрементальных подзадач
Демон компилятора, который также значительно ускоряет компиляцию.
Что касается управления зависимостями, то и Gradle, и Maven могут работать с динамическими и переходными зависимостями, использовать сторонние кэши зависимостей и читать формат метаданных POM. Вы также можете объявлять версии библиотек через центральное определение версий и обеспечивать централизованное версионирование. Оба продукта загружают переходные зависимости из своих репозиториев артефактов. Maven имеет Maven Central, а Gradle — JCenter, кроме того, вы можете определить свой собственный репозиторий компании. Если требуется несколько зависимостей, Maven может загружать их одновременно.
Gradle, однако, выигрывает, когда речь идет о зависимостях API и реализации, а также о возможности одновременного безопасного кэширования. Он также хранит метаданные репозитория вместе с кэшированными зависимостями, гарантируя, что два или более проектов, использующих один и тот же кэш, не перезапишут друг друга, а также имеет кэш на основе контрольной суммы и может синхронизировать кэш с репозиторием. Кроме того, Gradle совместим с IVY Metadata, что позволяет определять пользовательские правила для указания версии для динамической зависимости и разрешать конфликты версий. Эти возможности недоступны в Maven.
Ниже приведены другие возможности управления зависимостями, которые вы можете найти только в Gradle:
Использование правил подстановки для совместимых библиотек
Использование правил ReplacedBy
Более качественное управление метаданными
Возможность динамической замены проектных зависимостей на внешние и наоборот.
Gradle также облегчает работу с составными сборками, позволяя работать со специальными и постоянными составными сборками, а также объединять различные сборки и импортировать составную сборку в Eclipse или IntelliJ IDEA.
Что касается моделей выполнения, то обе имеют группы задач и описания. Обе позволяют собирать только указанный проект и его зависимости. Gradle, однако, имеет полностью настраиваемую DAG, в то время как в Maven цель может быть привязана только к одной другой цели. Несколько целей имеют форму упорядоченного списка. Gradle также позволяет исключать задачи, делать переходные исключения и определять зависимости между задачами. По сравнению с другими решениями Gradle также имеет расширенные возможности для упорядочивания задач и финализаторов.
Примеры кода
В сравнении Ant, Gradle и Maven Нареш Джоши сравнивает код, необходимый для создания сценария сборки, который компилирует, выполняет статический анализ, запускает модульные тесты и создает JAR-файлы на сайте Programming Mitra.
Вот код, необходимый для достижения этой цели с помощью Maven:
Чтобы запустить задачу Maven, создающую JAR-файл, выполните следующее:
Обратите внимание, что используя этот код, вы задаете параметры, но не указываете задачи, которые должны быть выполнены. Вы можете добавить плагины (такие как Maven CheckStyle, FindBugs и PMD) для выполнения статического анализа как единой цели вместе с юнит-тестами, но вы захотите указать путь к конфигурации пользовательского стиля проверки, чтобы убедиться, что он не сработает при ошибке, используя такой код, как:
Чтобы запустить задачу для достижения этой цели, выполните следующее:
Для выполнения некоторых основных и общих задач требуется довольно много XML-кода, и по этой причине проекты в Maven с большим количеством задач и зависимостей могут привести к файлам pom.xml, состоящим из сотен и тысяч строк кода.
Этот код короче, а также вводит некоторые полезные задачи, которые не рассматриваются в коде Maven выше. Выполните следующие действия, чтобы получить список задач, которые Gradle может выполнять с текущей конфигурацией:
Как выбрать?
В целом, оба инструмента имеют свои сильные и слабые стороны.
Индивидуальные сборки. С помощью Maven вы можете легко определить метаданные и зависимости вашего проекта, но создание очень индивидуальной сборки может стать кошмаром для пользователей Maven. Файл POM может легко раздуться по мере роста проекта и впоследствии превратиться в нечитаемый XML-файл.
Управление зависимостями и структура каталогов. Тем не менее, Maven обеспечивает простое, но эффективное управление зависимостями, а поскольку он имеет структуру каталогов для ваших проектов, у вас есть своего рода стандартная схема для всех ваших проектов. Он использует декларативный XML-файл для своего POM-файла и имеет множество плагинов, которые вы можете использовать. Gradle использует структуру каталогов, которую вы видите в Maven, но она может быть настроена. Он также использует тот же формат GAV, который Maven использует для идентификации артефактов.
Плагины и интеграции. Maven также поддерживает широкий спектр этапов жизненного цикла сборки и легко интегрируется со сторонними инструментами, такими как CI-серверы, плагины покрытия кода, системы репозиториев артефактов и др. Что касается плагинов, то в настоящее время количество доступных плагинов растет, и есть крупные поставщики, у которых есть плагины, совместимые с Gradle. Тем не менее, количество доступных плагинов для Maven все еще больше, чем для Gradle.
Гибкость. Gradle, с другой стороны, очень гибкий и основан на скрипте. Пользовательские сборки было бы легко делать на Gradle. Однако, поскольку Gradle практически недавно появился, количество разработчиков, знающих Gradle изнутри, может быть ограничено.
В конечном счете, выбор будет зависеть в первую очередь от того, что вам нужно. Gradle более мощный. Однако бывает так, что вам не нужно большинство возможностей и функций, которые он предлагает. Maven может подойти для небольших проектов, а Gradle — для более крупных. Если вы работали с Maven и обнаружили, что ваш проект перерос его, можно перейти с Maven на Gradle.
Дополнительные ресурсы и обучающие материалы по Gradle и Maven
Для дальнейшего чтения и получения дополнительной информации, включая полезные учебные пособия, посетите следующие ресурсы:
Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
Изучаем Gradle: что умеет система сборки приложений Android Studio
Содержание статьи
Большинство программистов, разрабатывающих для Android, хотя бы слышали о системе автоматической сборки Gradle. При этом, по моим наблюдениям, лишь немногие из использующих эту систему кодеров уделяют достаточно времени, чтобы как следует изучить ее возможности :). Самая частая причина звучит так: «Да ладно, это ж просто скрипт сборки, у меня есть задачи поважнее».
А ведь на самом деле Gradle может быть очень полезен как для простой настройки сборки, так и для решения весьма нестандартных задач! Об этом и пойдет речь сегодня.
Android Gradle plugin
Gradle сам по себе ничего не знает о том, как билдить Android-проект, в этом ему помогает плагин, который разрабатывается вместе с Android SDK. Если ты только недавно начал осваивать программирование под Android, то мог и не заметить, что в главном сборочном скрипте build.gradle студия самостоятельно добавляет зависимость от этого плагина.
Перед тем как мы попытаемся глубже разобраться в работе самого Gradle, я покажу тебе несколько полезных вещей, которые умеет делать этот плагин и о которых ты мог не знать.
Добавляем свои поля в BuildConfig
BuildConfig — это автоматически генерируемый при сборке класс, который содержит только константы. Этот класс генерируется отдельно для каждого модуля в твоем проекте и по умолчанию включает в себя информацию об ID приложения, версии, типе сборки.
Редактирование вручную этого файла бесполезно, так как он все равно перезатрется новыми данными при сборке. Зато Android-плагин может добавлять в него те поля, которые ты скажешь.
Первый параметр — тип константы, второй — имя, третий — значение, все просто. Заметь, что значение поля TIMEOUT вычисляется на этапе сборки и в BuildConfig попадет уже как число 300 000. Теперь ты можешь конфигурировать свой любимый HTTP-клиент, просто ссылаясь на константы в BuildConfig.
Добавляем свои данные в ресурсы
Принцип точно такой же, что и с BuildConfig, но позволяет добавлять значения в файл ресурсов. Но зачем добавлять ресурс из конфига, если проще это сделать, как обычно, в XML-файле? Просто потому, что в скрипте, так же как и в случае с BuildConfig.TIMEOUT, значение ресурса можно вычислить. Например, сохранить дату сборки:
Gradle создаст специальный файл generated.xml примерно такого содержания (только, разумеется, с правильными угловыми скобочками):
И пусть тебя не смущает, что мы храним время в формате String. К сожалению, Android SDK не умеет хранить в ресурсах long, а в 32-битный integer время не влезет.
Создаем разные варианты сборки
Мы используем build types, чтобы иметь возможность собирать приложение с существенными отличиями. Эти отличия обычно связаны с тем, как мы собираем приложение: для отладки или для релиза, с обфускацией кода или без, каким сертификатом оно будет подписано.
Product flavors дополняют build types и вносят еще один уровень гибкости в настройку сборки. Используй их, когда нужно, скажем так, не глобально изменить приложение, — это могут быть брендинг (иконки, цвета, тексты), окружение (адрес сервера, платформа, trial- или pro-версии).
Рис. 1. Выбор Build Variant в Android Studio
Настраиваем информацию о приложении
С таким конфигом команда gradle assembleTrialRelease соберет тебе приложение с applicationId=»example.myawesomeapp.release» и названием версии MyAwesomeApp-trial.
Заканчивая тему с Android-плагином для Gradle, нужно сказать, что это только часть его возможностей. Плагин постоянно развивается и приобретает новые фичи. На сайте tools.android.com есть подробный гайд по его использованию.
Gradle DSL
А теперь давай попробуем разобраться, почему конфигурация сборки в Gradle называется скриптом, из чего состоит этот скрипт и почему он выглядит так, как выглядит. Gradle часто называют объединением систем сборки Ant и Maven.
С одной стороны, Gradle, как и Maven, обеспечивает декларативный подход к сборке, когда программист лишь объявляет нужные значения и параметры, а система сама знает, как сделать всю остальную работу самостоятельно. Именно этим мы занимались в предыдущей части.
С другой стороны, Gradle, как и Ant, умеет выполнять команды, но пишутся они не в XML-файле, а уже с помощью Gradle DSL (domain-specific programming language), написанном на Groovy. В мире Gradle эти команды называются Tasks (задачи). Задачи можно делать зависимыми от других задач и таким образом строить граф их выполнения. По сути, цепочка задач и установленные параметры и есть скрипт сборки приложения.
Рис. 2. Типичный набор задач в Android-проекте
Xakep #212. Секреты даркнета
Прежде чем мы напишем что-то действительно полезное, давай я тебе покажу еще пару примеров манипулирования задачами.
Пример 1: добавляем зависимости к задаче
Мы написали две задачи, печатающие отдельно слова Hello и world. Операция doLast <. >и используется для краткости записи. Последняя задача greetings принимает в качестве зависимости массив других задач. Если запустить ее, то она самостоятельно запустит все задачи, от которых зависит.
Есть еще один вариант установки зависимостей:
Этот способ работает, потому что задачи в Gradle — это объекты, у них есть методы, их можно передавать в качестве параметра в функции.
Пример 2: динамическое создание задач
Подобно тому, как Android-плагин автоматически генерирует задачи под твои build types и product flavors, ты сам можешь генерировать свои задачи.
Такой скрипт создаст тебе пять задач с именами task0, tasl1 и так далее.
Практика
ОK, ближе к делу, давай напишем что-нибудь полезное. Многие проекты состоят не только из одного основного модуля app, но и из нескольких вспомогательных, каждый из которых имеет свой скрипт build.gradle со своими настройками. При обновлении Android SDK становится утомительно обновлять каждый из скриптов отдельно и редактировать в них compileSdkVersion, buildToolsVersion, targetSdkVersion. Зато можно написать задачу, которая сделает это самостоятельно. Открой скрипт build.gradle в корне своего проекта, найди в нем секцию allprojects <. >и добавь такой код:
Следующая задача посложнее: автоматизировать подстановку версии приложения (versionCode и versionName). Давай представим, что в проекте используется Git, каждый релиз помечается соответствующим тегом в формате release2.3.4. Тогда в качестве versionName можно будет брать имя самого свежего тега, а versionCode будет равняться количеству этих тегов. В качестве бонуса сгенерируем файл с историей релизов.
Для начала нужно написать функцию, вытаскивающую с Git всю нужную информацию.
Реальное значение зависит, конечно, от того, что на самом деле лежит в Git проекта. Эту функцию мы можем использовать в секции android, чтобы заполнить значения versionCode и versionName:
Автоподстановку версии мы настроили. Осталось записать список релизов в файл. Сделаем для этого новую задачу:
Так как Groovy — это дополнение к Java, у тебя в распоряжении весь стандартный Java API. Здесь, например, нам пригодился стандартный Java-класс File. Чтобы генерировать этот файл не вручную, а вместе с билдом, подцепим нашу задачу к какой-нибудь из уже имеющихся, например к preBuild:
Итого
Мы посмотрели на штатные возможности Android-плагина для Gradle, немного поковыряли Gradle API, поучились писать свои задачи. Разумеется, все это только верхушка айсберга. Вокруг Gradle уже сформировалось большое комьюнити, и оно развивает и создает свои плагины: для деплоя, для тестирования, для статистики и кучу других, которые могут сделать твою жизнь лучше. А если ты не найдешь то, что тебе нужно, то ты сможешь написать свой плагин или задачу. Успехов!
Видео доклада о внутреннем устройстве Gradle (на английском):
Gradle under the hood (Dawid Kublik)
Сборка Java-проекта с использованием Gradle
Этот урок освещает создание вами простого Java-приложения с использованием Gradle.
Что вы создадите
Вы создадите простое приложение и соберете его с помощью Gradle.
Что вам потребуется
Как проходить этот урок
Как и большинство уроков по Spring, вы можете начать с нуля и выполнять каждый шаг, либо пропустить базовые шаги, которые вам уже знакомы. В любом случае, вы в конечном итоге получите рабочий код.
Чтобы начать с нуля, перейдите в Настройка проекта.
Настройка проекта
Для начала вам необходимо настроить Java-проект перед тем, как собрать его Gradle’ом. Т.к. урок посвящен Gradle, сделаем проект максимально простым, насколько это возможно.
Создание структуры каталогов
Установка Gradle
Теперь, когда у вас есть проект, который вы можете собрать с Gradle, вам нужно установит сам Gradle.
Gradle можно получить, скачав zip-файл с gradle.org/downloads. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем gradle-version-bin.zip. (Вы также можете выбрать gradle-version-all.zip, тем самым получите исходники, документацию и бинарные файлы.)
Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.
Чтобы протестировать правильность установки Gradle, запустите в командной строке:
Если всё было сделано правильно, то вы увидите сообщение:
Теперь у вас есть установленный Gradle.
Что может делать Gradle
Теперь, когда Gradle установлен, посмотрим, что он может делать. Прежде, чем вы создадите build.gradle для проекта, выможете проверить, какие доступны задачи:
Вы должны увидеть список доступных задач. Если вы запустите Gradle в каталоге, в котором нет ещё файла build.gradle, то увидите несколько самых элементарных задач:
Говоря о добавлении плагинов, в следующей части урока вы добавите плагин, который отвечает за базовую функциональность сборки Java-проектов.
Сборка Java кода
Начнем с простого, создадим очень простой build.gradle в корневой папке проекта(там, где src), который содержит только одну строчку:
Эта единственная строчка в конфигурации сборки приносит значительную пользу. Запустите gradle tasks снова и вы увидите новые задачи в списке, включая задачи для сборки проекта, создания JavaDoc и запуска тестов.
Вы будете изпользовать задачу gradle build достаточно часто. Эта задача компилирует, тестирует и упаковывает код в JAR-файл. Вы можете запустить её таким образом:
Через несколько секунд, «BUILD SUCCESSFUL» будет означать, что сборка прошла успешно.
На данный момент проект не имеет зависимостей от библиотек, поэтому ничего нет в папке dependency_cache.
Каталог отчетов должен содержать отчет о выполнении тестов для проекта. Т.к. проект пока не содержит тестов, данный отчет будет нам неинтересен.
Каталог библиотек должен содержать JAR-файл с названием каталога проекта. В дальнейшем, вы увидите, как указывать имя JAR-файла и его версию.
Объявление зависимостей
Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.
К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.
Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.
Если бы вы запустили gradle build для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке.
Во-вторых, вам необходимо добавить источники сторонних библиотек:
Блок repositories означает, что сборка должна разрешать зависимости из Maven Central репозитория. Gradle опирается в основном на многие соглашения и возможности, определенные в инструменте сборки Maven, включая использование Maven Central как источник библиотек зависимостей.
Теперь, когда мы готовы к приему сторонних библиотек, объявим их:
В блоке dependencies вы описываете единственную зависимость Joda Time. В частности, вы запрашиваете(читаем справа на лево) версию 2.2 библиотеки joda-time в joda-time группе.
И наконец, назначим имя для нашего JAR артефакта.
Сборка проекта с Gradle Wrapper
Gradle Wrapper является предпочтительным способом для начала Gradle сборки. Он содержит bat-скрипты для Windows и shell-скрипты для OS X и Linux. Эти скрипты позволяют вам запускать сборку с Gradle без необходимости установки самого Gradle в вашу систему. Чтобы это стало возможным, добавьте следующий блок в конец вашего build.gradle :
Запустите следующую команду для загрузки и инициализации wrapper-скриптов:
Gradle Wrapper теперь доступен вам для сборки проекта. Добавьте его в вашу систему контроля версий и каждый, кто клонирует ваш проект, сможет его собрать точно таким же способом. Gradle Wrapper можно использовать наравне с установленным Gradle. Pfgecnbnt wrapper-скрипт для выполнения задичи сборки точно так же, как вы делали ранее:
Ранее, когда вы запускали wrapper с конкретной версией Gradle, он загружал и кешировал бинарники Gradle для соответствующей версии. Gradle Wrapper спроектирован таким образом, чтобы было возможно сохранить его в репозитории вашей VCS и любой, кто его клонирует, сможет собрать ваш проект без необходимости устанавливать и настраивать Gradle определенной версии.
На данном этапе у вас есть собранный ваш код. В результате вы увидете:
Это содержимое пакета файлов классов. Важно отметить, что даже, если вы и объявили joda-time как зависимость, библиотека не включена в пакет. И JAR-файл будет неспособен к выполнению.
Затем просто запустите ваше приложение!
Остановимся подробнее на упаковке зависимостей. К примеру, если бы мы собирали WAR-файл, общепризнанный формат, ассоциирующийся с упаковкой сторонних зависимостей, мы бы могли использовать WAR плагин. Если вы используете Spring Boot и хотите получить исполняемый JAR-файл, тогда вам пригодится spring-boot-gradle-plugin. На данном этапе, gradle недостаточно знает о выбранной вами системе. Но этого достаточно, чтобы приступить к работе с gradle.
В конечном счете, у вас должен получиться такой build.gradle файл:
Поздравляем! Вы создали простой, но эффективный файл сборки Gradle для сборки Java проектов.