Что такое gradle java
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 в сравнении с 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
Для дальнейшего чтения и получения дополнительной информации, включая полезные учебные пособия, посетите следующие ресурсы:
Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
Многомодульный 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: магия автоматической сборки
Разработчики облегчают жизнь людям, а Gradle — разработчикам. Если вы пишете на Android, эта статья для вас. Читайте о том, что за зверь этот Gradle (спойлер: он слон), а также — как с ним работать.
Gradle — система автоматической сборки, которую используют для упрощения работы с Java. С помощью (условно) стандартизированных средств она помогает разработчикам собрать нужный продукт без потери его уникальности. Ведь процесс работы с Gradle — не просто выбор шаблона. Но обо всём по порядку.
Где скачать Gradle
Скачать Gradle можно на официальном сайте. Рекомендуем качать и устанавливать всё вручную (чтобы жизнь малиной не казалась). Инструкция, а также все необходимые ссылки даны в разделе Installing Gradle > Installing Manually. Кстати, рекомендуем прочитать всё. Вообще всё. Серьёзно.
Иногда выходит так, что во время определения система находит Gradle в неожиданном месте. На Windows это решается следующим образом:
for %i in (gradle.bat) do echo. %
Как работать с Gradle
Gradle не привязан к конкретной платформе. К тому же, в системе используют разные языки программирования. Наиболее популярные — Groovy DSL и Kotlin (но можно писать и на других). В статье будет использован первый вариант, так как это стандартный язык описания задач в Gradle.
Прежде чем начинать работу, обратите внимание на термины: «задача» и «плагин», ещё раз. Ведь именно на них строится вся работа с системой. Плагины предоставляют и создают задачи. Задачи — те действия, которые надо сделать. Всё очень просто.
Подробнее об этом вы можете прочитать в инструкции к плагинам: JavaCompile (добавить новые задачи), SourceSet (добавить новые объекты домена). Также плагины работают с соглашениями и расширяют объекты. Например, с помощью плагина можно добавить новые элементы DSL и (или) настроить их.
Набор «Core Plugins» автоматически создаётся при установке Gradle. На первых этапах рекомендуют использовать категорию «Utility», а именно — плагин «Build Init Plugin». Он предоставляет задачи для инициализации проекта в системе. Выбрать тип проекта можно из списка на сайте.
После этого в папке появятся новые файлы. В их числе:
В последнем файле будет отображена секция плагина. Этот плагин уже имеет прикреплённые к нему задачи. Их список можно посмотреть с помощью команды gradle tasks.
Задачи
Показаны блоками, по своим функциям. К каждой даётся краткое описание. Для понимания требуется знание английского на базовом уровне. Если вы не входите в эту группу — подойдёт любой переводчик. Сложных языковых конструкций в build.gradle нет.
После выбора задачи и её успешного завершения вы увидите внизу зелёную надпись «BUILD SUCCESSFUL». Это значит, что (вам повезло) всё прошло без проблем. Также внизу система выдаст краткий отчёт.
Если статус «executed» — задача действительно выполнена. Если «up-to-date» — нет. Это не значит, что произошёл какой-то сбой. В случае такого статуса задача не требует решения в принципе, т. е. её объект уже в актуальном состоянии.
Это произошло потому, что в Gradle автоматически формируется «Up-to-date checks» — инкрементальный билд, цель которого — оптимизация работы системы. Поэтому задачи, которые уже завершены или не требуют действий, не прорабатываются.
Зависимости
Управление зависимостями — указание библиотек или фреймворков, которые нужны проекту. Gradle должна включить эти зависимости в определённый момент, чтобы в конце собрать приложение корректно (или вообще). Команда gradle init для java-application в build-скрипте автоматически вызывает информацию о 2 конфигурациях.
Implementation отвечает за транзитивность: её зависимости будут невидимыми для пользователей. TestImplementation расширяет предыдущую конфигурацию. Таким образом, они работают в связке.
Чтобы лучше понять зависимости и принцип работы с ними, прочтите главу «Managing Dependency Configurations» в официальной инструкции. Кстати, в «API and implementation separation» подробно объясняется про API и implementation, а также разницу между ними.
Если необходимо включить зависимость в итоговый артефакт, требуется указать всю необходимую для манифеста jar-файла информацию в настройках задачи jar. Как это сделать правильно, можете посмотреть, например, здесь.
Далее нужно включить в jar зависимости. Это необходимо для компиляции.
Слишком сложно? Используйте «Gradle Shadow Plugin».
Наиболее частые виды зависимостей:
Что из этого списка использовать, решает разработчик.
Для Java всё хорошо расписано в «Dependency management».
Лайфхаки
Несмотря на то, что Gradle — популярная и актуальная система автоматической сборки, проблемы в работе с ней возникают у многих. Вот несколько рекомендаций, которые могут значительно облегчить жизнь android-разработчику:
Используйте консоль. Найти команды иногда бывает проблематично, а при изменении build.gradle система может заглючить или, вообще, перезагрузить проект. Поэтому специалисты рекомендуют вызывать Gradle прямо из консоли.
Враппер обычно идёт вместе с проектом. На Linux и macOS можно обращаться напрямую. На Windows — вызывать вместо враппера bat-файл.
Gradle хранит кэш 1 сутки. Это можно перенастроить. Необходимо отредактировать код:
– –refresh-dependencies — полезная команда, которая запустит обновление всех зависимостей в Gradle. Может пригодиться, если какие-то данные в кэше повредились, так как верифицирует. Удобно использовать при повреждении данных кэша, так как происходит их верификация и обновление (если отличаются).
Используйте CI (непрерывную интеграцию) в работе с системой автоматической сборки. Пусть модульные тесты выполняются для всех коммитов. Также специалисты рекомендуют подключать и unit-тесты. Это можно сделать в Android Studio.
Такая комбинация позволит обнаружить ошибки раньше. И хотя она замедлит процесс запуска, разработчик сможет отдохнуть в дальнейшем. Так что лайфхак на перспективу.
Try again. Страшно? (Нам тоже) На самом деле синхронизацию не всегда нужно сразу запускать заново. Сначала специалисты рекомендуют проверить систему в целом. Например, с помощью любой простой команды — это поможет понять, каковы шансы на успех следующей синхронизации.
Настройте с Gradle среду разработки IntelliJ IDEA. Это позволит оптимизировать процесс работы, а также воспользоваться волшебным списком.
Совет для тех, кто работает с Gradle из командной строки Android Studio. Проверьтесь на ошибку «Starting a Gradle Daemon, 1 incompatible could not be reused» (#68374709). Это бич системы, который разработчики пока не исправили.
Одна из основных проблем Gradle — «Gradle build failed». Обойдёмся без лишних слов, если вам это уже знакомо. Если же нет — удачи.
Впрочем, главная проблема Gradle другая. Время, которое требуется системе на сборку, уже давно стало (очень печальной) легендой в кругах специалистов. Ускорить работу нельзя, по крайней мере — значительно.
Так что придётся ждать в любом случае.
Можете, например, слетать куда-нибудь в космос, как в «Интерстеллар».
Вывод
Gradle — это хорошее решение, несмотря на все минусы. Автоматическая сборка позволит вам сэкономить силы и время (как иронично это бы ни звучало после предыдущего абзаца). А также — сделать своё приложение чище. Система заметит любую ошибку и не позволит закончить работу, пока та не будет исправлена (любой ценой).