в какой папке по умолчанию gradle java plugin ищет исходный код для юнит тестов
Многомодульный 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»
Итог четвертого шага:
Шаг 5 (заключительный). Убираем мусор
Основная цель достигнута, но на данном этапе могли возникнуть вполне закономерные вопросы о дублировании информации в build файлах, более глубокой настройке gradle, а также о том, что изучать дальше. Для самостоятельного изучения, я советую ознакомиться с содержимым ссылок в конце статьи. А пока, давайте приведем в порядок наши build файлы, создав build.gradle в корне проекта и изменив содержимое остальных build файлов
На этом я закончу. Надеюсь, данная статья вызвала интерес у людей, не знакомых с Gradle, и побудила к более подробному изучению и последующему использованию в своих проектах этого инструмента.
Gradle Plugin: Что, зачем и как?
Доброго времени, читатель! В предыдущей статье мы рассмотрели, как эффективно использовать стандартные инструменты Gradle в проектах для решения повседневных задач и немного коснулись подкапотного пространства.
Под катом статьи проведём тур по Gradle-плагинам, разберёмся, для чего вы можете писать кастомные плагины уже сейчас, проникнемся процессом разработки на примере реализации плагина для Kotlin-кодогенерации и научимся обходить некоторые Gradle-грабли.
В первой части статьи проведём небольшой теоретический экскурс и рассмотрим способы реализации плагинов, а во второй части двинемся к практической задаче и проникнемся разработкой плагина для Kotlin-кодогенерации. Для реализации Gradle-задумок по ходу статьи я буду использовать Kotlin. Заваривайте ваш любимый напиток и поехали.
Gradle Plugin: Что, зачем и как?
Краткое введение в Gradle-плагины
Итак, Gradle-плагины представляют собой контейнеры, которые могут содержать в себе настраиваемую логику и различные задачи для сценариев сборки проекта.
Плагины полностью автономны и позволяют хранить логику для её повторного использования в нескольких проектах или Gradle-модулях. Они замечательно подходят для любых задач, требующих работы с исходным кодом. Такими задачами могут быть кодогенерация / генерация документации / проверка кода / запуск задач на CI / деплой и многое другое.
С точки зрения кода, плагин представляет собой реализацию примитивного интерфейса с единственным методом apply:
Project-ом является Gradle-проект (или Gradle-модуль), куда подключается плагин. Сам по себе интерфейс Project больше похож на God Object, поскольку в нём доступен сразу весь Gradle API, что, в принципе, достаточно удобно.
Gradle предлагает разработчикам несколько способов реализации плагинов (как и практически всего в Gradle). Дальше рассмотрим каждый способ по-отдельности и определим его плюсы и минусы.
Реализация плагина в build.gradle(.kts)
Самый простой вариант – реализовать плагин прямо внутри файла конфигурации. Да, просто берём и пишем класс по примеру выше в build.gradle(.kts). Если честно, трудно понять, какой пользой обладает такое решение, ведь Gradle уже предоставляет возможность обратиться project-у из файла конфигурации и накрутить его нужной логикой. А вот недостатков получаем сразу несколько.
Во-первых, подключить такой плагин можно только в текущий скрипт, в связи с чем теряется и суть плагина в возможности его повторного использования. Во-вторых, плагин будет компилироваться каждый раз при конфигурации проекта, что негативно повлияет на производительность сборки. На мой субъективный взгляд, от такого варианта можно отказаться и при необходимости дописать нужную логику прямо в скрипте конфигурации. Давайте перейдём к более жизнеспособным вариантам.
Реализация плагина в buildSrc
Модуль buildSrc компилируется и поставляется на этап конфигурации проекта в виде jar, поэтому реализовав плагин в buildSrc, получаем возможность его использования в Gradle-модулях проекта. Однако из-за известных проблем c инвалидацией кеша, реализация плагинов в buildSrc имеет право на жизнь в том случае, если для вашего проекта buildSrc представляет собой около-константный модуль, в котором редко происходят изменения.
Также такой вариант также является более компромиссным в сравнении со standalone-плагинами с точки зрения затрат на реализацию и вполне может подойти для небольших проектов.
Допустим, такой вариант нам подходит. Выполним подготовительный шаг и подключим в buildSrc плагин Kotlin DSL. Он сделает всю грязную работу по подключению Kotlin, подключит Gradle API и ещё м.
Кладём реализацию плагина в buildSrc/src/main/kotlin. Охапка дров, плагин готов. Теперь можно подключать плагин в проект с помощью apply :
Нагляднее будет подключать плагин c помощью id, поэтому давайте его зададим. Плагин Kotlin DSL транзитивно подключает Java Gradle Plugin Development Plugin, который предоставляет такую возможность:
В результате будет создан следующий файл:
src/main/resources/META-INF/gradle-plugins/ru.myorg.demo.my-plugin.properties
, который Gradle бережно положит в jar и дальше сможет соотносить id плагина с его реализацией. Теперь подключить плагин к проекту можно так:
Script-плагины
В Gradle присутствует интересная возможность реализовать плагин в виде скрипта. Скриптовый плагин по структуре идентичен скриптам конфигурации build.gradle(.kts) и может быть реализован как на Groovy, так и на Kotlin. При реализации на Kotlin существует достаточно весомое ограничение – скрипты должны находиться либо в buildSrc, либо в standalone Gradle-проекте, чтобы быть скомпилированными.
Приятным бонусом script-плагинов является автоматическая генерация id. Это сделает за нас Gradle Plugin Development Plugin, исходя из названия скрипта.
Важно: При реализации и использовании script-плагинов необходимо учесть следующие ограничения, связанные с версиями Gradle:
При реализации script-плагина в отдельном проекте и его подключении через композитную сборку, необходимо использовать Gradle версии 7.1 и выше из-за бага, при котором падала сборка после подключения плагина Kotlin DSL. Во всех проектах, куда подключается плагин с помощью композитной сборки, также необходимо использовать Gradle 7.1 и выше.
Script-плагины, написанные на Kotlin, можно подключать в проекты, использующие Gradle 6 и выше.
Script-плагины, написанные на Groovy, можно подключать в проекты, использующие Gradle 5 и выше.
Script-плагины можно писать на Kotlin, начиная с Gradle 6.0, и на Groovу, начиная с Gradle 6.4.
Лучше всегда держать версию Gradle в актуальном состоянии и не забивать голову лишними вопросами.
Попробуем script-плагин в деле
Давайте проведём небольшой эксперимент. Попробуем вынести в script-плагин на Kotlin общую конфигурацию Android-модулей и сделаем это в buildSrc.
Подключаем Android Gradle Plugin:
Теперь напишем сам плагин:
buildSrc/src/main/kotlin/android-common.gradle.kts:
Жмём Gradle Sync и получаем следующее время конфигурации: BUILD SUCCESSFUL IN 2m 6s
Почему так много? Я начал разбираться и первым делом зашёл в папку buildSrc/build, немного покопался и увидел там следующее:
Из этой грустной истории можно сделать вывод, что c подключением сторонних плагинов в script-плагине необходимо быть вдвойне аккуратными, а лучше и вовсе отказаться от этой идеи в пользу классов. Потеря в удобстве, на мой взгляд, незначительная. Попробуем реализовать тот же функционал с помощью класса:
В коде выше android <> будет самописным Kotlin-екстеншном:
Получаем следующее время конфигурации: BUILD SUCCESSFUL in 48s
и никакого лишнего кодгена. Not bad, not terrible. Замеры проводил на рабочем проекте, поэтому ваши результаты могут отличаться. А чтобы плагин было удобно подключать, генерируем ему id и в buildSrc самостоятельно напишем Kotlin-екстеншн:
Получилось ничем не хуже, и такой вариант вполне безопасно использовать.
Небольшой, но важный оффтоп про Kotlin-екстеншны для подключения плагинов
В ходе статьи можно заметить, что некоторые плагины удобным образом подключаются с помощью Kotlin-екстеншнов. Дело в том, что они хитро вшиты в сам Gradle, и написать собственный екстеншн получится только при реализации плагина в buildSrc. Если же плагин реализован в standalone-проекте, то при попытке использования самописного екстеншна получаем ошибку компиляции. Проблема актуальна вплоть до Gradle 7.1. Очень ждём, что это будет исправлено будущих релизах.
Теперь давайте двинемся дальше и рассмотрим полноценные standalone-плагины.
Standalone-плагин на примере кодогенерации
Standalone-плагин подразумевает реализацию в отдельном Gradle-проекте. Такой способ является наиболее предпочтительным, поскольку позволяет избежать всех недостатков buildSrc и script-плагинов. Если вы не хотите создавать отдельный git-репозиторий и планируете использовать плагин внутри одного проекта, то можно воспользоваться возможностью композитной сборки.
Планомерно приступим к небольшой практической задаче. Создадим новый проект и подключим всё, что нужно:
В зависимости добавим Kotlin Poet, с помощью которого будет реализована кодогенерация и Kotlin Gradle Plugin, который поможет интегрировать сгенерированный код в компиляцию JVM-проекта.
Теперь давайте определимся с параметрами плагина и с тем, как их передавать.
Конфигурация плагина
Для примера в качестве параметра сделаем файл с каким-нибудь сообщением. Это сообщение будет использоваться в качестве значения переменной в сгенерированном классе. Также в параметрах будем передавать рутовую директорию для кодогенерации и название пакета для сгенерированного класса.
Для передачи параметров в плагин в Gradle используются extension-контейнеры, которые, по своей сути, ничем не отличаются от обычных классов. В нашем случае extension-контейнер может выглядеть следующим образом:
Контейнер должен быть abstract или open классом, поскольку Gradle будет хитро создавать его инстанс с помощью рефлексии.
Для хранения параметров вместо стандартных переменных следует использовать специальные Gradle properties. Они обеспечивают оптимизацию потребления памяти благодаря ленивой инициализации и дают возможность сконфигурировать плагин в случае, если входные параметры заранее неизвестны и будут установлены позже (например, после выполнения другой Gradle-таски). Для проперти также можно указать дефолтное значение на случай, если к моменту обращения в ней не лежит никакого значения.
Создать и зарегистрировать extension-контейнер можно так:
Последним параметром передается аргумент (или аргументы) для конструктора. Идеально, если единственным аргументом будет project, но спроектировать можно как угодно. Созданный extension можно использовать в скриптах конфигурации build.gradle(.kts) следующим образом:
Теперь самое время создать саму Gradle-таску, которая будет выполнять кодогенерацию:
Аннотацией @TaskAction помечена функция, с которой таска начинает своё выполнение. Геттеры и сеттеры для Kotlin-пропертей помечены специальными Gradle-аннотациями, чтобы таска имела возможность выполняться инкрементально, то есть не выполняться, когда на то нет необходимости. Кому любопытно, полный исходный код доступен на моём Github.
Теперь давайте сделаем так, чтобы сгенерированный файл успешно компилировался. Директорию, в которой осуществляется кодогенерация, добавим в основной sourceSet. Таким образом явно объявим, что в директории хранится исходный код, который должен быть скомпилирован. С помощью afterEvaluate дождёмся окончания конфигурации, чтобы убедиться, что sourceSets уже были созданы.
Регистрируем кодген-таску, а саму компиляцию вежливо просим её подождать:
Всё готово к использованию. Получившийся плагин можно изучить под спойлером:
Воспользуемся композитной сборкой, чтобы подключить плагин в проект:
settings.gradle.kts:
Прежде чем нажать на Build, положим в корень проекта файл с сообщением. Собираем проект и видим созданный в build/src-gen созданный класс.
Ура! Теперь сгенерированный класс можно использовать в проекте. Самое время протестировать реализованное.
Тестирование плагина
В первую очередь, ребята из Gradle советуют тестировать плагин ручками. То есть, подключаем плагин с помощью композитной сборки к проекту и пользуемся всеми радостями дебаггинга.
Например, чтобы отдебажить конфигурацию плагина, выбираем интересующую нас таску из раздела Run Configurations и жмём Debug. Аналогично можно дебажить любые Gradle-таски.
Для автоматического тестирования Gradle-плагина предусмотрено три варианта: функциональные, интеграционные и модульные тесты.
Для функциональных и интеграционных тестов выполним подготовительный шаг и создадим кастомные sourceSets. Никто не запрещает делать всё в одном сете с модульными тестами, однако подход с раздельными sourceSet позволяет подключать только необходимые для конкретного вида тестов зависимости и в целом изолировать тесты друг от друга.
Чтобы запускать тесты из кастомных sourceSet, самостоятельно создадим соответствующие Gradle-таски. Для удобства запуска всех тестов сразу, свяжем их в стандартную таску check. В итоге конфигурация для интеграционных и функциональных тестов будет выглядеть следующим образом:
Конфигурация для интеграционных и функциональных тестов
build.gradle.kts (Gradle-проект с плагином):
Интеграционное тестирование плагина
Теперь приступим к разработке интеграционного теста, в котором проверим взаимодействие плагина с внешней средой, а именно с файловой системой. Здесь мы всё ещё ничего не знаем о Gradle и проверяем работу бизнес-логики.
Создаём одноимённую для соответствующего sourceSet директорию в /src и реализуем тест.
src/integrationTest/kotlin/
Функциональное тестирование плагина
Теперь перейдём к самому интересному – функциональным тестам. Они позволяют проверить работу плагина целиком совместно с Gradle и его жизненным циклом. Для этого будем запускать настоящий Gradle Daemon. Конфигурация функциональных тестов практически ничем не отличается от конфигурации интеграционных тестов, за тем исключением, что больше не нужна зависимость на модуль с Gradle-плагином.
Чтобы запустить Gradle Daemon, необходимо создать и сконфигурировать Gradle Runner. Для этого добавляем Gradle Runner API в classpath для функциональных тестов следующим образом:
В тесте эмулируем структуру проекта, конфигурируем Gradle Runner, запускаем и смотрим что получилось. Сам тест лежит под спойлером:
src/functionalTest/kotlin/
Отлично! Плагин протестировали, можно похвалить себя чем-то приятным. Осталось дело за малым – задеплоить плагин.
Деплой плагина во внешний репозиторий
Для этого воспользуемся плагином Maven Publish. Формируем публикацию и объявляем список репозиториев, в которые она сможет публиковаться:
Итоги
Gradle-плагины представляют собой действительно мощный инструмент для дополнения логики сборки необходимыми для вас задачами. К сожалению, в Gradle API по-прежнему много загадок и непонятных проблем, в том числе не до конца раскрытых в документации. Это создаёт препятствия на пути к удобству использования, однако команда Gradle над этим активно работает.
На рабочих проектах мы широко используем Gradle-плагины для хранения общей логики сборки, выполнения специфической кодогенерации, а также выполнения различных инфраструктурных задач на CI. А какие задачи решаете вы с помощью Gradle-плагинов? Напишите в комментариях. Также я открыт к любым обсуждениям по материалу, буду рад замечаниям и предложениям.
Всё изложенное в статье доступно на Github.
Ниже представлю небольшой список opensource-плагинов, в исходниках которых можно подчерпнуть идеи для реализации:
Запуск простых тестов JUnit на Android Studio (IntelliJ) при использовании конфигурации на основе Gradle
Если я создаю новую исходную папку и помечаю ее как таковой в структуре проекта, это будет очищено в следующий раз IntelliJ обновляет конфигурацию проекта из файлов сборки gradle.
Обычно вы не можете. Добро пожаловать в мир Android, где все тесты должны выполняться на устройстве (кроме Robolectric).
Там замечательный проект под названием Robolectric, который реализует многие рамки только для того, чтобы вы могли запускать осмысленные тесты. В сочетании с хорошей макетной каркасной структурой (например, Mockito) она делает вашу работу управляемой.
Введение
Чтобы использовать Robolectric в Android Studio, у вас есть 2 варианта:
(Вариант 1) – Запуск тестов JUnit с помощью Android Studio с использованием модуля Java
Этот метод использует java-модуль для всех ваших тестов с зависимостью вашего модуля android и пользовательского тестового бегуна с некоторой магией:
Также проверьте ссылку в конце этого сообщения для запуска тестов из студии android.
У меня возникли проблемы с настройкой junit-тестов для запуска из gradle в Android Studio.
Это очень простой пример проекта для запуска тестов junit из проекта gradle в Android Studio: https://github.com/hanscappelle/android-studio-junit-robolectric Это было протестирован с Android Studio 0.8.14, JUnit 4.10, robolectric gradle плагин 0.13+ и robolectric 2.3
Buildscript (project/build.gradle)
Строка script – это файл build.gradle в корне вашего проекта. Там мне пришлось добавить robolectric gradle плагин в classpath
Проект buildscript (App/build.gradle)
Создать классы тестирования JUnit
Теперь поместите тестовые классы в папку по умолчанию (или обновите gradle config)
Выполнение тестов
Затем выполните тесты с использованием gradlew из командной строки (при необходимости выполните его с помощью chmod +x )
Устранение неполадок
альтернативные исходные каталоги
пакет org.junit не существует
Вы забыли добавить зависимость теста junit в приложении build script
java.lang.RuntimeException: Stub!
Пример полной ошибки:
ОШИБКА: JAVA_HOME установлен в недопустимый каталог
См. этот вопрос SO для решения. Добавьте ниже представленный вам профиль bash:
Полный журнал ошибок:
Класс тестирования не найден
Если вы хотите запускать тесты из бегуна Android Studio Junit Test, вам придется немного расширить файл build.gradle, чтобы студия Android могла находить ваши скомпилированные тестовые классы:
Еще несколько ресурсов
Лучшие статьи, которые я нашел по этому поводу:
Теперь это поддерживается в Android Studio, начиная с Android Gradle plugin 1.1.0, проверьте это:
Пример приложения с локальными модульными тестами в GitHub:
Для Android Studio 1.2 + настройка проекта для JUnit довольно проста. Попробуйте следовать этому руководству:
Это простейшая часть, создающая проект для JUnit:
Следуйте по предыдущей ссылке до тех пор, пока Запуск тестов
Теперь, если вы хотите интегрироваться с тестом интрументации, следуйте отсюда:
Пожалуйста, ознакомьтесь с этим учебник на официальном сайте разработчиков Android. В этой статье также показано, как создавать макеты для вашего тестирования.
Кстати, вы должны заметить, что область зависимостей для простого теста JUnit должна быть “testCompile”.
Сборка 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 проектов.