Я оставил JavaOne 2011 с несколькими блюдами на вынос . Одним из наиболее значительных был возобновленный интерес к изучению Gradle . В этой статье я расскажу об использовании Gradle и о переносе простого скрипта сборки Ant в Gradle.
Gradle установка проста. Gradle можно загрузить и распаковать в нужное место. Я использую Gradle 1.0 Milestone 6 для примеров в этом посте.
После загрузки и разархивирования Gradle переменная среды GRADLE_HOME может быть установлена в каталог разархивированной установки Gradle, а значение PATH должно быть равно $ GRADLE_HOME / bin или% GRADLE_HOME% \ bin. Страница установки Gradle сообщает нам, что параметры JVM, используемые Gradle, могут быть установлены либо через GRADLE_OPTS, либо через JAVA_OPTS . Установку и настройку Grade в пути можно подтвердить, запустив gradle -v в командной строке после получения параметров переменной среды.
Помимо проверки правильности конфигурации установки Gradle, вывод при запуске опции -v также напоминает нам, что Gradle построен (и использует лучшие из них) Groovy (1.8.4), Ant (1.8.2), Ivy (2.2). 0) и виртуальная машина Java для выполнения нашей задачи.
В документации по основам скрипта сборки Gradle описан стандартный скрипт сборки конфигурации (что-то вроде файла Ant build.xml), называемый build.gradle. На этой же странице представлен пример реализации Hello, World такого сценария конфигурации сборки. Адаптированная версия этого примера показана в следующем листинге кода.
build.gradle — Пример Hello Gradle
task hello_world {
doLast {
println 'Hello, Gradle!'
}
}
Задача (примерно эквивалентная цели Ant) определена выше с именем «hello_world» и может быть вызвана Gradle так же, как Ant вызывает задачу Ant (при условии, что в обоих случаях используются имена файлов сценариев конфигурации сборки по умолчанию): gradle Привет мир. Следующий снимок экрана показывает это как с опцией -q (для тихого режима), так и без нее.
Интересным наблюдением, которое я сделал, играя даже с этим простым файлом конфигурации сборки, является важность правильного размещения фигурных скобок. Начальная фигурная скобка в той же строке, что и объявление задачи, должна оставаться в этой строке. Когда я попытался переместить его на следующую строку, чтобы выстроить в строку в том же столбце, что и закрывающая фигурная скобка, я увидел ошибку в следующем снимке экрана и типичном текстовом выводе, который следует за изображением.
Сообщение об ошибке при открытии фигурной скобки на следующей строке
FAILURE: Build failed with an exception.
* Where:
Build file 'C:\java\examples\groovyExamples\gradleExample\build.gradle' line: 2
* What went wrong:
Could not compile build file 'C:\java\examples\groovyExamples\gradleExample\build.gradle'.
Cause: startup failed:
build file 'C:\java\examples\groovyExamples\gradleExample\build.gradle': 2: Ambiguous expression could be a parameterless closure expression, an isolated open code block, or it may continue a previous statement;
solution: Add an explicit parameter list, e.g. {it -> ...}, or force it to be treated as an open block by giving it a label, e.g. L:{...}, and also either remove the previous newline, or add an explicit semicolon ';' @ line 2, column 1.
{
^
1 error
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 2.636 secs
К счастью, вышеприведенного сообщения об ошибке легко избежать, поместив открывающую фигурную скобку закрытия задачи Gradle на ту же строку, что и определение задачи Gradle.
Цель по умолчанию может быть указана в Ant build.xml через атрибут элемента проекта по умолчанию. Gradle поддерживает аналогичную спецификацию задач по умолчанию для запуска, как показано в следующем фрагменте кода, который основан на предыдущем примере. Выполнение этой задачи теперь не требует указания задачи, как показано на следующем снимке экрана.
build.gradle — Пример Hello Gradle со значениями по умолчанию
defaultTasks 'hello_world'
task hello_world {
doLast
{
println 'Hello, Gradle!'
}
}
Gradle специально создан, чтобы быть гибким и поддерживать широкий спектр задач. Для тех, кто интересуется конкретными, часто используемыми задачами, существуют подключаемые модули Gradle, чтобы уменьшить потребность во вновь написанном коде Grade. Для целей этого поста плагин Java представляет особый интерес. Этот плагин легко применить, как показано в следующей версии build.gradle, основанного на предыдущих двух примерах и добавляющего приложение плагина Java.
build.gradle — Пример Hello Gradle с подключаемым модулем Java
apply plugin: 'java'
defaultTasks 'hello_world'
task hello_world {
doLast
{
println 'Hello, Gradle!'
}
}
Простое добавление плагина apply в одну строку : java автоматически переносит множество связанных с Java задач в этот файл конфигурации сборки. Я думаю, что самый простой способ быстро определить, какие задачи автоматически доступны через плагин Java, — это запускать gradle-задачи для файла конфигурации сборки, в котором не применяется плагин, а затем запускать gradle-задачи для файла конфигурации сборки с примененным плагином Java. Это показано на следующих двух снимках экрана. (Обратите внимание, что задачи gradle похожи на параметр Ant -p, за исключением того, что Ant требует, чтобы атрибут описания цели был указан, чтобы цель отображалась в ответ на параметр -p.)
Сравнение этих двух снимков экрана помогает нам увидеть, какие задачи стали доступны с помощью плагина Java в Gradle. Прежде чем рассматривать конкретные задачи Java, я думаю, что стоит также отметить некоторые другие задачи, доступные в Gradle без плагина («Задачи справки»). В частности, изображения обозначают задачу «задачи» (одну из «задач справки»), которую мы использовали для просмотра всех доступных задач. Существуют аналогичные встроенные задачи «Справка» для просмотра свойств сборки («свойства»), просмотра зависимостей проекта («зависимости»), просмотра подпроектов («проекты») и просмотра справки («справка»). Многие из этих задач также доступны через устаревшие параметры командной строки.
Единственная другая задача, указанная для файла конфигурации сборки, которая не применяла подключаемый модуль Java, была заданная пользователем задача hello_world. Однако в файле конфигурации сборки, в котором была добавлена единственная строка для применения плагина Java, было множество других задач, помимо поставляемой пользователем задачи «hello_world» и помимо всегда доступных «справочных задач». Эти задачи включают в себя «Задачи сборки» («сборка», «сборка», «buildDependents», «buildNeeded», «классы», «очистка», «jar», «testClasses»), «Задачи документации» («javadoc») и «Задачи проверки» («проверка» и «проверка»).
Также интересно увидеть синтаксис цвета, используемый в выходных данных для запуска задач gradle. Это приятное прикосновение, которое повышает читабельность вывода. Если по какой-либо причине синтаксис цвета нежелателен, можно указать параметр —no-color, чтобы отключить его.
Соглашение о конфигурации — это все более популярный принцип разработки программного обеспечения, в который вошли такие инструменты и платформы, как Ruby on Rails , Maven и JPA («конфигурация за исключением»). Gradle аналогично принимает соглашения с задачами плагина Java, чтобы уменьшить потребность в явной спецификации конфигурации.
Страница быстрого запуска Gradle Java описывает соглашения Gradle для плагина Java (я добавил акцент ):
Gradle ожидает найти ваш производственный исходный код в src / main / java и ваш тестовый исходный код в src / test / java. Кроме того, любые файлы в каталоге src / main / resources будут включены в файл JAR в качестве ресурсов, а любые файлы в каталоге src / test / resources будут включены в путь к классам, используемый для запуска тестов. Все выходные файлы создаются в каталоге build, а файл JAR заканчивается в каталоге build / libs.
Соглашения Gradle для сборок Java могут выглядеть подозрительно похожими на соглашения, с которыми пользователи Maven уже знакомы.
Для целей этого сообщения в блоге я изменил свое личное соглашение о каталогах, вдохновленное NetBeans, для работы с ожидаемым соглашением Gradle. Другими словами, вместо того, чтобы использовать dist для созданного JAR и использовать src и test для исходного и тестового кода соответственно, я перемещаю файлы в src / main / java и test / main / java и планирую собрать JAR в создать каталог, а не в каталоге dist.
С исходным кодом в соответствующем ожидаемом каталоге я показываю (на следующем снимке экрана) создание кода Java с помощью задачи «build» и генерацию Javadoc с помощью задачи «javadoc». Опять же, синтаксис цвета делает вывод более читабельным.
На следующем снимке экрана показаны созданные файлы в каталоге сборки. Ничего из этого не было указано, поскольку оно опиралось на условности Грэдла.
Две папки «blogScriptConfigFiles» и «images» не являются частью сборки Gradle и являются просто папками, которые я создал для управления версиями файлов build.gradle и снимками экрана для этого сообщения в блоге. Другие папки являются исходными или сгенерированными артефактами.
В случае, если выше не было ясно, я хотел бы добавить напоминание, что для сборки и документирования этого простого Java-приложения мне действительно нужен только следующий файл конфигурации сборки Gradle:
build.gradle — минимум, необходимый для сборки простого Java-приложения
apply plugin: 'java'
Пока исходные файлы находятся в соответствующем месте в соответствии с соглашениями Gradle и сборка не слишком сложна, мне вообще не нужно указывать какие-либо задачи (подобные целям Ant). В свой блог я включил простой пример build.xml « Изучение Java с помощью простых тестов», который я часто использую в качестве отправной точки для создания простых примеров Java. Однако, даже самый простой файл сборки Ant не так прост, как только что показанный файл конфигурации Gradle с одной строкой!
Вывод
У Gradle большой потенциал в качестве инструмента для сборки. Объединяя мощь Groovy с мощью JVM Ant и Ivy, Gradle, похоже, готова предоставить выигрышную комбинацию, которую непросто будет выиграть, когда речь идет о создании приложений Java. Я с нетерпением жду Gradle 1.0, оставив статус Milestone позади, надеюсь, в самом ближайшем будущем.
От http://marxsoftware.blogspot.com/2011/11/first-look-at-building-java-with-gradle.html