Про Gradle для любопытных.
Вот раньше был Ant. Простой и понятный инструмент для сборки проектов. Открываешь xml-ку и видишь: здесь мы хотим скомпилировать файлы, здесь скопировать всё в папку dist, а здесь сделать jar-ик.
Потом придумали Maven. Это была небольшая революция. Искать и подключать популярные библиотеки стало намного проще. Все стали использовать приблизительно одинаковую структуру проектов (исходники хранились в одной папке, конфигурационные файлы – в другой, тесты – в третьей).
В результате, в некоторых программерских компаниях разработчиков стали насильно пересаживать на Maven. Так наступило время, в течение которого процесс сборки проектов для некоторых программистов был окутан туманом.
Разобраться, как работает Maven; понять, что означают все эти тэги – было весьма затруднительно. Всё взаимодействие ограничивалось, как правило, запуском команды mvn clean install. Для многих это действие означало что-то похожее на взмах волшебной палочки с параллельным произнесением заклинаний: “Expelliarmus” или “Avada Kedavra“.
Введение в Gradle
Любая проблема, требующая каких-либо нестандартных исправлений в pom.xml, первым делом решалась поиском “нужного заклинания” в stackoverflow или Google. Главная причина недовольства, которое высказывали многие программисты, что не понятно как и в какой последовательности всё работает. Например, что нужно сделать, чтобы просто скопировать файлик и затем выложить его на ftp (или запустить обфускатор)?
Тем не менее, Maven постепенно занял свое место в умах людей. Кто-то из любопытствующих и упорных в итоге разобрался в его внутреннем устройстве. Кто-то просто свыкся. Но время идет, мода меняется. Находятся люди, для которых уже и Мaven – это неудобный и даже архаичный инструмент.
Время не щадит никого…
Что пишут учебники про Gradle.
Отчасти мода на Gradle продиктована Google-ом, т.к. Android SDK сейчас во всю использует именно его. Возможно Maven и дальше будет вытесняться Gradle, хотя бы в силу того, что последний синтаксически проще: Вместо того, чтобы писать в pom.xml:
com.squareup.okhttp okhttp 2.2.0
Мы пишем в файле build.gradle:
compile ‘com.squareup.okhttp:okhttp:2.2.0’
Но что такое Gradle на самом деле?
Почти каждому программисту, который только начинает разбираться с Gradle, говорят, что это всего-то “DSL на базе Groovy для сборки проектов”. Дальше приводятся примеры, как сделать свой проект на Java, какую команду запустить для компиляции, как вызвать ant-овые задачи (Да, Gradle фактически из коробки может работать с Ant, что радует).
Первым делом приводят пример файла gradle.build:
task hello < doLast < println «hello world» >>
Это пример, который приводится в каждом учебнике по Gradle.
Вроде как создается впечатление, что все понятно. На самом же деле, далеко не каждый Java-программист знаком с синтаксисом Groovy. И далеко не каждый представляет, что такое DSL, или Domain Specific Language, так как в обычной жизни не так уж и часто приходится с ним встречаться. Поэтому объяснение “DSL на Groovy для сборки проектов” создает массу новых вопросов. Очень хочется узнать– а какой именно DSL?
Степан Гончаров — Gradle от A до Я
А как он сделан? Неужели и правда там просто Groovy?
Поэтому лично мне стало любопытно, как этот Gradle устроен внутри.
Хотя, по правде говоря, если бы Google не внес изменения в свое Android SDK и не перешел бы на Gradle, я бы так и сидел на Ant и Maven.
Что скрывается внутри.
Итак, если грубо, то DSL на Groovy – это просто Groovy-скрипт с набором удобных и готовых функций для сборки проектов. Такой подход – не экзотика. Например, в Scala есть sbt – “свой DSL на Scala”, который используется для этой же цели.
Другими словами, gradle.build – это просто программа на Groovy. Со своей спецификой, с набором библиотек и функций из коробки, но все-таки – программа на Groovy.
Соответственно, если это просто Groovy-скрипт, то у вас так же заработает build.gradle, который содержит только:
println «hello world»
Более того, теоретически вы можете написать и более изощренный скрипт. Например, такой:
def count = 0; new groovy.swing.SwingBuilder().frame(title:’Frame’, size:[300,300], show: true) < borderLayout() textlabel = label(text:»Click the button!», constraints: java.awt.BorderLayout.NORTH) button(text:’Click Me’, actionPerformed: , constraints:java.awt.BorderLayout.SOUTH) > Thread.sleep(10000);
– который выдаст такую картинку:
Конечно, это чисто теоретически. Практического смысла в такого рода скриптах сборки (которые показывают формочки с кнопками) я не вижу и не призываю писать аналогичные скрипты.
Это просто демонстрация того, что Gradle не такой уж страшный, и, по сути, его скрипты – это обычные программы.
С самим языком программирования Groovy я сталкиваюсь крайне редко и последний раз писал на нем очень давно.
Поэтому, возможно, для многих Groovy-программистов следующие вещи будут очевидными. Но (опять-таки), поскольку Gradle-ом пользуются не только гуру Groovy-разработки, думаю, следующие объяснения будет любопытно прочитать многим.
В Groovy можно опускать скобки для методов, которые имеют всего один аргумент.
println(«hello»)
можно просто написать:
println «hello»
Оба варианта будут работать одинаково.
Рассмотрим еще один пример.
task hello < doLast < println “hello world” >>
Мы видим, что doLast – это всего-навсего вызов doLast( // некоторая анонимная функция , точнее – кложура);
task hello < doLast (< println (“hello world”); >); >
Мы вызываем doLast и передаем ей на вход кложур, в котором нужно выполнить println(“hello”);
В качестве иллюстрации вот приблизительная и грубая аналогия того, как это могло бы выглядеть на Java:
task.doLast(new Closure() < public void call() < System.out.println(“hello world”); >>);
Естественно внутри, на самом деле, все гораздо сложнее. Кому любопытно – можете на свой страх и риск посмотреть, в какой конкретно классик преобразуется наш скрипт.
Место, куда складываются скомпилированные скрипты, может отличаться. У меня они оказались здесь:
“C:Users$.gradlecaches$scripts”.
Итак, приближаемся к самому интересному.
Самое интересное.
Когда мы смотрим на начало скрипта (который приводится в каждом учебнике по Gradle):
task hello
– мы видим и понимаем, что это не Groovy синтаксис!
Что такое hello? Если это строка, то тогда должны быть кавычки: task “hello”.
Если это имя переменной, то откуда она? Она нигде не объявлена. Предопределенной она тоже не может быть, так как название может быть каким угодно. Откуда компилятор может знать, как я назову задачу?
Почему после hello идут фигурные скобки?
В конце концов, что такое task? Если это функция, почему мы передаем непонятное hello? Мы знаем, что скобки можно опускать только от функции одной переменной, а здесь у нас два параметра.
На самом деле нет никакого смысла пытаться разгадать эту загадку, используя знание синтаксиса языка Groovy.
Дело в том, что создатели Gradle перед выполнением скрипта обрабатывают его «напильником». Для любопытных: напильник называется TaskDefinitionScriptTransformer и лежит здесь.
Вот часть его исходного кода:
private void doVisitMethodCallExpression(MethodCallExpression call) < if (!isInstanceMethod(call, «task»)) < return; >ArgumentListExpression args = (ArgumentListExpression) call.getArguments(); if (args.getExpressions().size() == 0 || args.getExpressions().size() > 3) < return; >// Matches: task if (args.getExpressions().size() > 1) < if (args.getExpression(0) instanceof MapExpression args.getExpression(1) instanceof VariableExpression) < // Matches: task , , ? // Map to: task(, », ?) transformVariableExpression(call, 1); > else if (args.getExpression(0) instanceof VariableExpression) < // Matches: task , ? transformVariableExpression(call, 0); > return; > // Matches: task or task() Expression arg = args.getExpression(0); if (arg instanceof VariableExpression) < // Matches: task or task() transformVariableExpression(call, 0); > else if (arg instanceof BinaryExpression) < // Matches: task transformBinaryExpression(call, (BinaryExpression) arg); > else if (arg instanceof MethodCallExpression) < // Matches: task maybeTransformNestedMethodCall((MethodCallExpression) arg, call); > >
Фактически вводится новое, чисто Gradle-овое (ключевое) слово task, которое трансформирует скрипт перед выполнением и делает его Groovy-совместимым.
Сам Task также представляет интересную и довольно простую конструкцию.
Например, при внимательно рассмотрении можно увидеть в нем метод leftShift, который делает то же самое, что и метод doLast. Таким способом заменяется действие оператора “ 3 марта, 2015
Источник: programador.ru
Крибле Крабле 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. %~$PATH:i
Как работать с 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 прямо из консоли.
// build.gradle configurations.all
Одна из основных проблем Gradle — «Gradle build failed». Обойдёмся без лишних слов, если вам это уже знакомо. Если же нет — удачи.
Впрочем, главная проблема Gradle другая. Время, которое требуется системе на сборку, уже давно стало (очень печальной) легендой в кругах специалистов. Ускорить работу нельзя, по крайней мере — значительно.
Так что придётся ждать в любом случае.
Можете, например, слетать куда-нибудь в космос, как в «Интерстеллар».
Вывод
Gradle — это хорошее решение, несмотря на все минусы. Автоматическая сборка позволит вам сэкономить силы и время (как иронично это бы ни звучало после предыдущего абзаца). А также — сделать своё приложение чище. Система заметит любую ошибку и не позволит закончить работу, пока та не будет исправлена (любой ценой).
- android
- gradle
- android-development
- mobile development
- Разработка мобильных приложений
- Разработка под Android
- Gradle
Источник: habr.com
Gradle что это за программа
Согласен с Денисом. Статья ни о чем. Только начнет писать о чем то и тут же ссылка на официальную доку. К сожалению на этом ресурсе появилось много «пустых» статей. Вы их пишите ради какого то рейтинга?
25 апреля 2020
Возникает один вопрос. Зачем писать бесполезный пост, если можно обратиться к официальной документации. Обо всем и ни о чем.
Olga Ivanova Уровень 35
21 августа 2019
Спасибо за статью. Только начинаю разбираться с программированием под андроид. Подскажите пж, в андроид студио есть gradle — файлы, есть ли связь с Maven и как они работают. Если добавите пару абзацев про это в сабж, будет чудесно )
Андрей Уровень 29 Expert
4 марта 2019
Gradle — Ant на стероидах
Сообщество
JavaRush — это интерактивный онлайн-курс по изучению Java-программирования c нуля. Он содержит 1200 практических задач с проверкой решения в один клик, необходимый минимум теории по основам Java и мотивирующие фишки, которые помогут пройти курс до конца: игры, опросы, интересные проекты и статьи об эффективном обучении и карьере Java‑девелопера.
Подписывайтесь
Язык интерфейса
Скачивайте наши приложения
Этот веб-сайт использует данные cookie, чтобы настроить персонально под вас работу сервиса. Используя веб-сайт, вы даете согласие на применение данных cookie. Больше подробностей — в нашем Пользовательском соглашении.
Источник: javarush.com
Сборка Java-проекта с использованием Gradle
Этот урок освещает создание вами простого Java-приложения с использованием Gradle.
Что вы создадите
Вы создадите простое приложение и соберете его с помощью Gradle.
Что вам потребуется
- Примерно 15 минут свободного времени
- Любимый текстовый редактор или IDE
- JDK 6 и выше
Как проходить этот урок
Как и большинство уроков по 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
Внутри src/main/java/hello директории вы можете создать любые Java-классы, какие вы хотите. Для простоты и согласованности с остальной частью урока, Spring рекомендует вам создать два класса: HelloWorld.java и Greeter.java .
package hello; public class HelloWorld < public static void main(String[] args) < Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>
package hello; public class Greeter < public String sayHello() < return «Hello world!»; >>
Установка Gradle
Теперь, когда у вас есть проект, который вы можете собрать с Gradle, вам нужно установит сам Gradle.
Gradle можно получить, скачав zip-файл с gradle.org/downloads. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем gradle-version-bin.zip. (Вы также можете выбрать gradle-version-all.zip, тем самым получите исходники, документацию и бинарные файлы.)
Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.
Чтобы протестировать правильность установки Gradle, запустите в командной строке:
gradle
Если всё было сделано правильно, то вы увидите сообщение:
:help Welcome to Gradle 1.8. To run a build, run gradle . To see a list of available tasks, run gradle tasks To see a list of command-line options, run gradle —help BUILD SUCCESSFUL Total time: 2.675 secs
Теперь у вас есть установленный Gradle.
Что может делать Gradle
Теперь, когда Gradle установлен, посмотрим, что он может делать. Прежде, чем вы создадите build.gradle для проекта, выможете проверить, какие доступны задачи:
gradle tasks
Вы должны увидеть список доступных задач. Если вы запустите Gradle в каталоге, в котором нет ещё файла build.gradle, то увидите несколько самых элементарных задач:
:tasks == All tasks runnable from root project == Build Setup tasks setupBuild — Initializes a new Gradle build. [incubating] wrapper — Generates Gradle wrapper files. [incubating] == Help tasks dependencies — Displays all dependencies declared in root project ‘gs-gradle’. dependencyInsight — Displays the insight into a specific dependency in root project ‘gs-gradle’. help — Displays a help message projects — Displays the sub-projects of root project ‘gs-gradle’. properties — Displays the properties of root project ‘gs-gradle’. tasks — Displays the tasks runnable from root project ‘gs-gradle’. To see all tasks and more detail, run with —all. BUILD SUCCESSFUL Total time: 3.077 secs
Не смотря на то, что эти задачи доступны, они не представляют большого значения без конфигурации для сборки проекта. С build.gradle файлом, некоторые задачи будут более полезны. Список задач будет увеличиваться при добавлении плагинов в build.gradle , таким образом вы будете время от времени запускать tasks, чтобы проверить, какие задачи доступны.
Говоря о добавлении плагинов, в следующей части урока вы добавите плагин, который отвечает за базовую функциональность сборки Java-проектов.
Сборка Java кода
Начнем с простого, создадим очень простой build.gradle в корневой папке проекта(там, где src), который содержит только одну строчку:
apply plugin: ‘java’
Эта единственная строчка в конфигурации сборки приносит значительную пользу. Запустите gradle tasks снова и вы увидите новые задачи в списке, включая задачи для сборки проекта, создания JavaDoc и запуска тестов.
Вы будете изпользовать задачу gradle build достаточно часто. Эта задача компилирует, тестирует и упаковывает код в JAR-файл. Вы можете запустить её таким образом:
gradle build
Через несколько секунд, «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 , как показано ниже:
package hello; import org.joda.time.LocalTime; public class HelloWorld < public static void main(String[] args) < LocalTime currentTime = new LocalTime(); System.out.println(«The current local time is: » + currentTime); Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>
Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.
Если бы вы запустили gradle build для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке.
Во-вторых, вам необходимо добавить источники сторонних библиотек:
repositories
Блок repositories означает, что сборка должна разрешать зависимости из Maven Central репозитория. Gradle опирается в основном на многие соглашения и возможности, определенные в инструменте сборки Maven, включая использование Maven Central как источник библиотек зависимостей.
Теперь, когда мы готовы к приему сторонних библиотек, объявим их:
dependencies
В блоке 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 :
task wrapper(type: Wrapper)
Запустите следующую команду для загрузки и инициализации wrapper-скриптов:
gradle wrapper
После того, как задачи отработают, вы заметите несколько новых файлов. Два скрипта в корневом каталоге, а jar-файл и properties-файл оболочки будут в папке gradle/wrapper .
└── initial └── gradlew └── gradlew.bat └── gradle └── wrapper └── gradle-wrapper.jar └── gradle-wrapper.properties
Gradle Wrapper теперь доступен вам для сборки проекта. Добавьте его в вашу систему контроля версий и каждый, кто клонирует ваш проект, сможет его собрать точно таким же способом. Gradle Wrapper можно использовать наравне с установленным Gradle. Pfgecnbnt wrapper-скрипт для выполнения задичи сборки точно так же, как вы делали ранее:
./gradlew build
Ранее, когда вы запускали wrapper с конкретной версией Gradle, он загружал и кешировал бинарники Gradle для соответствующей версии. Gradle Wrapper спроектирован таким образом, чтобы было возможно сохранить его в репозитории вашей VCS и любой, кто его клонирует, сможет собрать ваш проект без необходимости устанавливать и настраивать Gradle определенной версии.
На данном этапе у вас есть собранный ваш код. В результате вы увидете:
build ├── classes │ └── main │ └── hello │ ├── Greeter.class │ └── HelloWorld.class ├── dependency-cache ├── libs │ └── gs-gradle-0.1.0.jar └── tmp └── jar └── MANIFEST.MF
В сборке содержатся два класса Greeter и HelloWorld , как и ожидалось, а также JAR-файл. Окиньте беглым взглядом:
$ jar tvf build/libs/gs-gradle-0.1.0.jar 0 Fri May 30 16:02:32 CDT 2014 META-INF/ 25 Fri May 30 16:02:32 CDT 2014 META-INF/MANIFEST.MF 0 Fri May 30 16:02:32 CDT 2014 hello/ 369 Fri May 30 16:02:32 CDT 2014 hello/Greeter.class 988 Fri May 30 16:02:32 CDT 2014 hello/HelloWorld.class
Это содержимое пакета файлов классов. Важно отметить, что даже, если вы и объявили joda-time как зависимость, библиотека не включена в пакет. И JAR-файл будет неспособен к выполнению.
Чтобы сделать этот код выполняемым, мы можем использовать плагин application . Добавьте его в ваш build.gradle файл.
apply plugin: ‘application’ mainClassName = ‘hello.HelloWorld’
Затем просто запустите ваше приложение!
$ ./gradlew run :compileJava UP-TO-DATE :processResources UP-TO-DATE :classes UP-TO-DATE :run The current local time is: 16:16:20.544 Hello world! BUILD SUCCESSFUL Total time: 3.798 secs
Остановимся подробнее на упаковке зависимостей. К примеру, если бы мы собирали WAR-файл, общепризнанный формат, ассоциирующийся с упаковкой сторонних зависимостей, мы бы могли использовать WAR плагин.
Если вы используете Spring Boot и хотите получить исполняемый JAR-файл, тогда вам пригодится spring-boot-gradle-plugin. На данном этапе, gradle недостаточно знает о выбранной вами системе. Но этого достаточно, чтобы приступить к работе с gradle.
В конечном счете, у вас должен получиться такой build.gradle файл:
apply plugin: ‘java’ apply plugin: ‘eclipse’ apply plugin: ‘application’ mainClassName = ‘hello.HelloWorld’ // tag::repositories[] repositories < mavenLocal() mavenCentral() >// end::repositories[] // tag::jar[] jar < baseName = ‘gs-gradle’ version = ‘0.1.0’ >// end::jar[] // tag::dependencies[] dependencies < compile «joda-time:joda-time:2.2» >// end::dependencies[] // tag::wrapper[] task wrapper(type: Wrapper) < gradleVersion = ‘1.11’ >// end::wrapper[]
Здесь присутствует много закомментированных открывающихся и закрывающихся вставок. Они позволяют разделить на части файл сборки для наглядного объяснения данного урока. Их необязательно использовать в вашем рабочем файле сборки.
Итог
Поздравляем! Вы создали простой, но эффективный файл сборки Gradle для сборки Java проектов.
С оригинальным текстом урока вы можете ознакомиться на spring.io.
Источник: spring-projects.ru
Введение в Gradle
Gradle — основанная на Groovy система управления сборкой, разработанная специально для создания проектов на основе Java.
Инструкции по установке можно найти here .
2. Строительные блоки — проекты и задачи
- В Gradle сборки состоят из одного или нескольких проектов, а каждый проект состоит из одной или нескольких задач. **
Проект в Gradle может собирать jar , war или даже zip файл.
- Задача — это отдельная работа. ** Это может включать компиляцию классов или создание и публикацию Java/веб-архивов.
Простая задача может быть определена как:
task hello < doLast < println ‘Baeldung’ >>
Если мы выполним вышеуказанную задачу, используя команду gradle -q hello из того же места, где находится build.gradle , мы должны увидеть вывод в консоли.
2.1. Задачи
Сценарии сборки Gradle — это не что иное, как Groovy:
task toLower < doLast < String someString = ‘HELLO FROM BAELDUNG’ println «Original: «+ someString println «Lower case: » + someString.toLowerCase() >>
Мы можем определить задачи, которые зависят от других задач. Зависимость задачи можно определить, передав аргумент dependsOn: taskName в определении задачи:
task helloGradle < doLast < println ‘Hello Gradle!’ >> task fromBaeldung(dependsOn: helloGradle) < doLast < println «I’m from Baeldung» >>
2.2. Добавление поведения к задаче
Мы можем определить задачу и улучшить ее с помощью некоторого дополнительного поведения:
task helloBaeldung < doLast < println ‘I will be executed second’ >> helloBaeldung.doFirst < println ‘I will be executed first’ >helloBaeldung.doLast < println ‘I will be executed third’ >helloBaeldung < doLast < println ‘I will be executed fourth’ >>
doFirst и doLast добавляют действия вверху и внизу списка действий соответственно, и могут быть определены несколько раз в одной задаче .
2.3. Добавление свойств задачи
Мы также можем определить свойства:
task ourTask
Здесь мы устанавливаем «theValue» как theProperty задачи ourTask .
3. Управление плагинами
В Gradle есть два типа плагинов — script, и binary.
Чтобы воспользоваться дополнительными функциями, каждый плагин должен пройти две фазы: resolving и applying.
- Resolving означает найти правильную версию jar плагина и добавить ее в classpath проекта.
- Applying plugins выполняет Plugin.apply (T) для проекта ** .
3.1. Применение скриптовых плагинов
В aplugin.gradle, мы можем определить задачу:
task fromPlugin < doLast < println «I’m from plugin» >>
Если мы хотим применить этот плагин к нашему файлу build.gradle проекта, все, что нам нужно сделать, это добавить эту строку в наш build.gradle :
apply from: ‘aplugin.gradle’
Теперь выполнение команды gradle tasks должно отобразить задачу fromPlugin в списке задач.
3.2. Применение бинарных плагинов с помощью плагинов DSL
В случае добавления основного двоичного плагина мы можем добавить короткие имена или идентификатор плагина:
plugins
Теперь задача run из плагина application должна быть доступна в проекте для выполнения любого runnable jar. Чтобы применить плагин сообщества, мы должны упомянуть полный идентификатор плагина:
plugins
Теперь задачи Shipkit должны быть доступны в списке gradle tasks .
Ограничениями плагинов DSL являются:
- Он не поддерживает Groovy-код внутри блока plugins
Блок plugins должен быть оператором верхнего уровня в сборке проекта
скрипты (перед ним разрешен только блок buildscripts <> ) ** Плагины DSL не могут быть написаны в плагине сценариев, settings.gradle
файл или в скриптах инициализации
Плагины DSL все еще инкубируют. DSL и другая конфигурация могут измениться в более поздних версиях Gradle.
3.3. Устаревшая процедура применения плагинов
Мы также можем применять плагины, используя «apply plugin» :
apply plugin: ‘war’
Если нам нужно добавить плагин сообщества, мы должны добавить внешний jar-файл в путь к классу сборки, используя блок buildscript <> .
Затем мы можем применить плагин в скриптах сборки, но только после любого существующего plugins <> блока :
buildscript < repositories < maven < url «https://plugins.gradle.org/m2/» >> dependencies < classpath «org.shipkit:shipkit:0.9.117» >> apply plugin: «org.shipkit.bintray-release»
4. Управление зависимостями
Gradle поддерживает очень гибкую систему управления зависимостями, она совместима с широким спектром доступных подходов.
Лучшие практики для управления зависимостями в Gradle — управление версиями, динамическое управление версиями, разрешение конфликтов версий и управление переходными зависимостями. **
4.1. Конфигурация зависимостей
Зависимости сгруппированы в разные конфигурации. Конфигурация имеет имя, и они могут расширять друг друга .
Если мы применим плагин Java, у нас будут доступны конфигурации compile, testCompile, runtime для группировки наших зависимостей. _Default c onfiguration расширяет « runtime» ._
4.2. Объявление зависимостей
Давайте рассмотрим пример добавления некоторых зависимостей (Spring и Hibernate) несколькими различными способами:
dependencies < compile group: ‘org.springframework’, name: ‘spring-core’, version: ‘4.3.5.RELEASE’ compile ‘org.springframework:spring-core:4.3.5.RELEASE’, ‘org.springframework:spring-aop:4.3.5.RELEASE’ compile( [group: ‘org.springframework’, name: ‘spring-core’, version: ‘4.3.5.RELEASE’], [group: ‘org.springframework’, name: ‘spring-aop’, version: ‘4.3.5.RELEASE’] ) testCompile(‘org.hibernate:hibernate-core:5.2.12.Final’) < transitive = true >runtime(group: ‘org.hibernate’, name: ‘hibernate-core’, version: ‘5.2.12.Final’) < transitive = false >>
Мы объявляем зависимости в различных конфигурациях: compile , testCompile и runtime в различных форматах.
runtime «org.codehaus.groovy:groovy-all:[email protected]» runtime group: ‘org.codehaus.groovy’, name: ‘groovy-all’, version: ‘2.4.11’, ext: ‘jar’
Чтобы добавить зависимости в любые локальные файлы, мы можем использовать что-то вроде этого:
compile files(‘libs/joda-time-2.2.jar’, ‘libs/junit-4.12.jar’) compile fileTree(dir: ‘libs’, include: ‘** .jar’)
- Когда мы хотим избежать транзитивных зависимостей, мы можем сделать это на уровне конфигурации или на уровне зависимости ** :
configurations < testCompile.exclude module: ‘junit’ >testCompile(«org.springframework.batch:spring-batch-test:3.0.7.RELEASE»)
5. Мультипроектные сборки
5.1. Жизненный цикл сборки
- На этапе инициализации Gradle определяет, какие проекты будут участвовать в многопроектной сборке. **
Обычно это упоминается в файле settings.gradle , который находится в корне проекта. Gradle также создает экземпляры участвующих проектов.
- На этапе настройки все созданные экземпляры проектов настраиваются на основе конфигурации функций Gradle по требованию. **
В этой функции только необходимые проекты настраиваются для выполнения конкретной задачи. Таким образом, время конфигурации значительно сокращается для большой многопроектной сборки. Эта функция все еще насиживает.
Наконец, на этапе выполнения выполняется подмножество задач, созданных и настроенных. Мы можем включить код в файлы settings.gradle и build.gradle для восприятия этих трех этапов.
println ‘At initialization phase.’
Источник: www.codeflow.site