Сборка Java-проекта с использованием Gradle
Этот урок освещает создание вами простого Java-приложения с использованием Gradle.
Что вы создадите
Вы создадите простое приложение и соберете его с помощью Gradle.
Что вам потребуется
- Примерно 15 минут свободного времени
- Любимый текстовый редактор или IDE и выше
Как проходить этот урок
Как и большинство уроков по Spring, вы можете начать с нуля и выполнять каждый шаг, либо пропустить базовые шаги, которые вам уже знакомы. В любом случае, вы в конечном итоге получите рабочий код.
Чтобы начать с нуля, перейдите в Настройка проекта.
-
и распакуйте архив с кодом этого урока, либо кнонируйте из репозитория с помощью Git: git clone https://github.com/spring-guides/gs-gradle.git
- Перейдите в каталог gs-gradle/initial
- Забегая вперед, установите Gradle
Когда вы закончите, можете сравнить получившийся результат с образцом в gs-gradle/complete .
Настройка проекта
Для начала вам необходимо настроить Java-проект перед тем, как собрать его Gradle’ом. Т.к. урок посвящен Gradle, сделаем проект максимально простым, насколько это возможно.
Создание структуры каталогов
В выбранном вами каталоге проекта создайте следующую структуру каталогов; к примеру, командой mkdir -p src/main/java/hello для *nix систем:
Внутри src/main/java/hello директории вы можете создать любые Java-классы, какие вы хотите. Для простоты и согласованности с остальной частью урока, Spring рекомендует вам создать два класса: HelloWorld.java и Greeter.java .
Установка 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, то увидите несколько самых элементарных задач:
Не смотря на то, что эти задачи доступны, они не представляют большого значения без конфигурации для сборки проекта. С build.gradle файлом, некоторые задачи будут более полезны. Список задач будет увеличиваться при добавлении плагинов в build.gradle , таким образом вы будете время от времени запускать tasks, чтобы проверить, какие задачи доступны.
Говоря о добавлении плагинов, в следующей части урока вы добавите плагин, который отвечает за базовую функциональность сборки Java-проектов.
Сборка Java кода
Начнем с простого, создадим очень простой build.gradle в корневой папке проекта(там, где src), который содержит только одну строчку:
Эта единственная строчка в конфигурации сборки приносит значительную пользу. Запустите gradle tasks снова и вы увидите новые задачи в списке, включая задачи для сборки проекта, создания JavaDoc и запуска тестов.
Вы будете изпользовать задачу gradle build достаточно часто. Эта задача компилирует, тестирует и упаковывает код в JAR-файл. Вы можете запустить её таким образом:
Через несколько секунд, «BUILD SUCCESSFUL» будет означать, что сборка прошла успешно.
- classes. Скомпилированные .class файлы
- reports. Отчеты в течении сборки(такие как отчеты о тестировании)
- libs. Библиотеки для сборки проекта(обычно в виде JAR и/или WAR файлов)
Классы в каталоге с .class файлами генерируются во время сборки Java-кода. Соответственно, вы должны найти там HelloWorld.class и Greeter.class.
На данный момент проект не имеет зависимостей от библиотек, поэтому ничего нет в папке dependency_cache.
Каталог отчетов должен содержать отчет о выполнении тестов для проекта. Т.к. проект пока не содержит тестов, данный отчет будет нам неинтересен.
Каталог библиотек должен содержать JAR-файл с названием каталога проекта. В дальнейшем, вы увидите, как указывать имя JAR-файла и его версию.
Объявление зависимостей
Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.
К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.
Во первых, изменим HelloWorld.java , как показано ниже:
Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.
Если бы вы запустили gradle build для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке.
Во-вторых, вам необходимо добавить источники сторонних библиотек:
Блок repositories означает, что сборка должна разрешать зависимости из Maven Central репозитория. Gradle опирается в основном на многие соглашения и возможности, определенные в инструменте сборки Maven, включая использование Maven Central как источник библиотек зависимостей.
Теперь, когда мы готовы к приему сторонних библиотек, объявим их:
В блоке dependencies вы описываете единственную зависимость Joda Time. В частности, вы запрашиваете(читаем справа на лево) версию 2.2 библиотеки joda-time в joda-time группе.
Другое, что хотелось бы отметить, это необходимость указания ключевого слова compile , обозначающее доступность библиотеки во время компиляции(а если бы вы собирали WAR файл, то была бы включена /WEB-INF/libs папка в WAR). Также существуют другие заметные ключевые слова, среди которых:
- providedCompile . Требуемые зависимости для компиляции кода, но которые будут доступны во время работы кода контейнера(например, Java Servlet API)
- testCompile . Зависимости, используемые для компиляции и запуска тестов, но не требуемые для компиляции и запуска кода проекта
И наконец, назначим имя для нашего JAR артефакта.
jar блок определяет, как JAR файл будет назван. В данном случае мы получим gs-gradle-0.1.0.jar .
Теперь, если мы запустим gradle build , Gradle должен будет загрузить Joda Time зависимость из репозитория Maven Central и успешно собрать проект.
Сборка проекта с Gradle Wrapper
Gradle Wrapper является предпочтительным способом для начала Gradle сборки. Он содержит bat-скрипты для Windows и shell-скрипты для OS X и Linux. Эти скрипты позволяют вам запускать сборку с Gradle без необходимости установки самого Gradle в вашу систему. Чтобы это стало возможным, добавьте следующий блок в конец вашего build.gradle :
Запустите следующую команду для загрузки и инициализации wrapper-скриптов:
После того, как задачи отработают, вы заметите несколько новых файлов. Два скрипта в корневом каталоге, а jar-файл и properties-файл оболочки будут в папке gradle/wrapper .
Gradle Wrapper теперь доступен вам для сборки проекта. Добавьте его в вашу систему контроля версий и каждый, кто клонирует ваш проект, сможет его собрать точно таким же способом. Gradle Wrapper можно использовать наравне с установленным Gradle. Pfgecnbnt wrapper-скрипт для выполнения задичи сборки точно так же, как вы делали ранее:
Ранее, когда вы запускали wrapper с конкретной версией Gradle, он загружал и кешировал бинарники Gradle для соответствующей версии. Gradle Wrapper спроектирован таким образом, чтобы было возможно сохранить его в репозитории вашей VCS и любой, кто его клонирует, сможет собрать ваш проект без необходимости устанавливать и настраивать Gradle определенной версии.
На данном этапе у вас есть собранный ваш код. В результате вы увидете:
В сборке содержатся два класса Greeter и HelloWorld , как и ожидалось, а также JAR-файл. Окиньте беглым взглядом:
Это содержимое пакета файлов классов. Важно отметить, что даже, если вы и объявили joda-time как зависимость, библиотека не включена в пакет. И JAR-файл будет неспособен к выполнению.
Чтобы сделать этот код выполняемым, мы можем использовать плагин application . Добавьте его в ваш build.gradle файл.
Затем просто запустите ваше приложение!
Остановимся подробнее на упаковке зависимостей. К примеру, если бы мы собирали WAR-файл, общепризнанный формат, ассоциирующийся с упаковкой сторонних зависимостей, мы бы могли использовать WAR плагин. Если вы используете Spring Boot и хотите получить исполняемый JAR-файл, тогда вам пригодится spring-boot-gradle-plugin. На данном этапе, gradle недостаточно знает о выбранной вами системе. Но этого достаточно, чтобы приступить к работе с gradle.
В конечном счете, у вас должен получиться такой build.gradle файл:
Поздравляем! Вы создали простой, но эффективный файл сборки Gradle для сборки Java проектов.
The Directories and Files Gradle Uses
Gradle uses two main directories to perform and manage its work: the Gradle user home directory and the Project root directory. The following two sections describe what is stored in each of them and how transient files and directories are cleaned up.
Gradle user home directory
The Gradle user home directory ( $USER_HOME/.gradle by default) is used to store global configuration properties and initialization scripts as well as caches and log files. It is roughly structured as follows:
| 1 | Global cache directory (for everything that’s not project-specific) |
| 2 | Version-specific caches (e.g. to support incremental builds) |
| 3 | Shared caches (e.g. for artifacts of dependencies) |
| 4 | Registry and logs of the Gradle Daemon |
| 5 | Global initialization scripts |
| 6 | JDKs downloaded by the toolchain support |
| 7 | Distributions downloaded by the Gradle Wrapper |
| 8 | Global Gradle configuration properties |
Cleanup of caches and distributions
From version 4.10 onwards, Gradle automatically cleans its user home directory. The cleanup runs in the background when the Gradle daemon is stopped or shuts down. If using —no-daemon , it runs in the foreground after the build session with a visual progress indicator.
The following cleanup strategies are applied periodically (at most every 24 hours):
Version-specific caches in caches/<gradle-version>/ are checked for whether they are still in use.If not, directories for release versions are deleted after 30 days of inactivity, snapshot versions after 7 days of inactivity.
Shared caches in caches/ (e.g. jars-* ) are checked for whether they are still in use.If there’s no Gradle version that still uses them, they are deleted.
Files in shared caches used by the current Gradle version in caches/ (e.g. jars-3 or modules-2 ) are checked for when they were last accessed.Depending on whether the file can be recreated locally or would have to be downloaded from a remote repository again, it will be deleted after 7 or 30 days of not being accessed, respectively.
Gradle distributions in wrapper/dists/ are checked for whether they are still in use, i.e. whether there’s a corresponding version-specific cache directory.Unused distributions are deleted.
Project root directory
The project root directory contains all source files that are part of your project. In addition, it contains files and directories that are generated by Gradle such as .gradle and build . While the former are usually checked in to source control, the latter are transient files used by Gradle to support features like incremental builds. Overall, the anatomy of a typical project root directory looks roughly as follows:
| 1 | Project-specific cache directory generated by Gradle |
| 2 | Version-specific caches (e.g. to support incremental builds) |
| 3 | The build directory of this project into which Gradle generates all build artifacts. |
| 4 | Contains the JAR file and configuration of the Gradle Wrapper |
| 5 | Project-specific Gradle configuration properties |
| 6 | Scripts for executing builds using the Gradle Wrapper |
| 7 | The project’s settings file where the list of subprojects is defined |
| 8 | Usually a project is organized into one or multiple subprojects |
| 9 | Each subproject has its own Gradle build script |
Project cache cleanup
From version 4.10 onwards, Gradle automatically cleans the project-specific cache directory. After building the project, version-specific cache directories in .gradle/<gradle-version>/ are checked periodically (at most every 24 hours) for whether they are still in use. They are deleted if they haven’t been used for 7 days.
Крибле Крабле Gradle: магия автоматической сборки
Разработчики облегчают жизнь людям, а Gradle — разработчикам. Если вы пишете на Android, эта статья для вас. Читайте о том, что за зверь этот Gradle (спойлер: он слон), а также — как с ним работать.
Gradle — система автоматической сборки, которую используют для упрощения работы с Java. С помощью (условно) стандартизированных средств она помогает разработчикам собрать нужный продукт без потери его уникальности. Ведь процесс работы с Gradle — не просто выбор шаблона. Но обо всём по порядку.
Где скачать Gradle
Скачать Gradle можно на официальном сайте. Рекомендуем качать и устанавливать всё вручную (чтобы жизнь малиной не казалась). Инструкция, а также все необходимые ссылки даны в разделе Installing Gradle > Installing Manually. Кстати, рекомендуем прочитать всё. Вообще всё. Серьёзно.
На этой странице нужно выбрать версию системы и кликнуть по «binary-only». Затем — распаковать zip-архив и настроить переменную среды окружения PATH так, как сказано в инструкции. Если всё сделано правильно, после установки команда gradle -v должна отображать версию выбранной системы.
Иногда выходит так, что во время определения система находит 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». Он предоставляет задачи для инициализации проекта в системе. Выбрать тип проекта можно из списка на сайте.
Пусть это будет java-application.
Задача: gradle init —type java-application
После этого в папке появятся новые файлы. В их числе:
- папка gradle (внимание, не .gradle) и файл gradlew.bat — это враппер, обёртка;
- файл build.gradle — скрипт, где указаны библиотеки, фреймворки, плагины и задачи конкретного проекта.
В последнем файле будет отображена секция плагина. Этот плагин уже имеет прикреплённые к нему задачи. Их список можно посмотреть с помощью команды gradle tasks.
Задачи
Показаны блоками, по своим функциям. К каждой даётся краткое описание. Для понимания требуется знание английского на базовом уровне. Если вы не входите в эту группу — подойдёт любой переводчик. Сложных языковых конструкций в build.gradle нет.
После выбора задачи и её успешного завершения вы увидите внизу зелёную надпись «BUILD SUCCESSFUL». Это значит, что (вам повезло) всё прошло без проблем. Также внизу система выдаст краткий отчёт.
Если статус «executed» — задача действительно выполнена. Если «up-to-date» — нет. Это не значит, что произошёл какой-то сбой. В случае такого статуса задача не требует решения в принципе, т. е. её объект уже в актуальном состоянии.
Это произошло потому, что в Gradle автоматически формируется «Up-to-date checks» — инкрементальный билд, цель которого — оптимизация работы системы. Поэтому задачи, которые уже завершены или не требуют действий, не прорабатываются.
Отключить этот build можно. Вручную. Для этого необходимо выполнить задачу с указанием флага —rerun-tasks. Если всё сделано правильно, статус у всех задач изменится на «executed».
Также Gradle позволяет просматривать логи разного уровня. Например, команда gradle run -i позволит читать информационные сообщения о работе системы, команда run -q — включить режим тишины, run -d — показывать все сообщения журнала и т. д. Полный список логов и дополнительная информация о системе логирования тут.
Зависимости
Управление зависимостями — указание библиотек или фреймворков, которые нужны проекту. Gradle должна включить эти зависимости в определённый момент, чтобы в конце собрать приложение корректно (или вообще). Команда gradle init для java-application в build-скрипте автоматически вызывает информацию о 2 конфигурациях.
Implementation отвечает за транзитивность: её зависимости будут невидимыми для пользователей. TestImplementation расширяет предыдущую конфигурацию. Таким образом, они работают в связке.
Чтобы лучше понять зависимости и принцип работы с ними, прочтите главу «Managing Dependency Configurations» в официальной инструкции. Кстати, в «API and implementation separation» подробно объясняется про API и implementation, а также разницу между ними.
Если необходимо включить зависимость в итоговый артефакт, требуется указать всю необходимую для манифеста jar-файла информацию в настройках задачи jar. Как это сделать правильно, можете посмотреть, например, здесь.
Далее нужно включить в jar зависимости. Это необходимо для компиляции.
Слишком сложно? Используйте «Gradle Shadow Plugin».
Команда gradle —console plain dependencies вызывает список всех конфигураций и привязанных к ним зависимостей в виде перечня. Также система предлагает разработчикам фильтр, который исключает из перечня зависимости (gradle —console plain dependencies | find » — «) — некоторым так удобнее.
Наиболее частые виды зависимостей:
- внешние — загружаются из внешних хранилищ;
- проектные — зависят от модуля в конкретном проекте;
- файловые — подключаются как jar- или aar-архивы.
Что из этого списка использовать, решает разработчик.
Для 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 — это хорошее решение, несмотря на все минусы. Автоматическая сборка позволит вам сэкономить силы и время (как иронично это бы ни звучало после предыдущего абзаца). А также — сделать своё приложение чище. Система заметит любую ошибку и не позволит закончить работу, пока та не будет исправлена (любой ценой).