Руководство по gradle

Время на прочтение
7 мин

Количество просмотров 73K

Как мне кажется, большинство людей начинают разбираться с gradle только тогда, когда в проекте что-то надо добавить или что-то внезапно ломается — и после решения проблемы «нажитый непосильным трудом» опыт благополучно забывается. Причём многие примеры в интернете похожи на ускоспециализированные заклинания, не добавляющие понимания происходящего:

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.habr.hello"
        minSdkVersion 20
        targetSdkVersion 28
    }
    buildTypes {
        release {
            minifyEnabled false
        }
    }
}

Я не собираюсь подробно описывать, для чего нужна каждая строчка выше — это частные детали реализации андроид-плагина. Есть кое-что более ценное — понимание того, как всё организовано. Информация раскидана по различным сайтам/официальной документации/исходникам градла и плагинов к нему — в общем, это чуть более универсальное знание, которое не хочется забывать.

Дальнейший текст можно рассматривать как шпаргалку для тех, кто только осваивает gradle или уже забыл.

Полезные ссылки

• Официальная документация Довольно объёмная, но местами может не хватать подробностей.
• исходники на github, javadoc — из-за динамической типизации в groovy среда разработки далеко не всегда может выдать список доступных полей/методов, а по коротким названиям методов и типам аргументов (Closure closure) не всегда можно понять, зачем они нужны.
• статья на хабре с кучей примеров — это перевод второй главы книги «Building and testing with gradle». Книжку тоже можно почитать, она находится в свободном доступе.
• ещё одна статья — про buildSrc

Консоль

Android studio/IDEA старательно прячет команды gradle от разработчика, а ещё при изменении build.gradle файликов начинает тупить или перезагружать проект.

В таких случаях вызывать gradle из консоли оказывается намного проще и быстрее. Враппер для gradle обычно идёт вместе с проектом и прекрасно работает в linux/macos/windows, разве что в последнем надо вызывать bat-файлик вместо враппера.

Вызов задач

./gradlew tasks

пишет доступные задачи.

./gradlew subprojectName:tasks --all

Можно вывести задачи отдельного подпроекта, а ещё с опцией --all будут выведены все задачи, включая второстепенные.

Можно вызвать любую задачу, при этом будут вызваны все задачи, от которых она зависит.

./gradlew app:assembleDevelopDebug

Если лень писать название целиком, можно выкинуть маленькие буковки:

./gradlew app:assembleDD

Если градл не сможет однозначно угадать, какую именно задачу имели ввиду, то выведет список подходящих вариантов.

Логгинг

Количество выводимой в консоль информации при запуске задачи сильно зависит от уровня логгинга.
Кроме дефолтного есть -q, -w, -i, -d, ну или --quiet, --warn, --info, --debug по возрастанию количества информации. На сложных проектах вывод с -d может занимать больше мегабайта, а поэтому его лучше сразу сохранять в файл и там уже смотреть поиском по ключевым словам:

./gradlew app:build -d > myLog.txt

Если где-то кидается исключение, для stacktrace опция -s.

Можно и самому писать в лог:

logger.warn('A warning log message.')

логгер является имплементацией SLF4J.

Groovy

Происходящее в build.gradle файликах — просто код на groovy.

Groovy как язык программирования почему-то не очень популярен, хотя, как мне кажется, он сам по себе достоин хотя бы небольшого изучения. Язык появился на свет ещё в 2003 году и потихоньку развивался. Интересные особенности:

• Практически любой java код является валидным кодом на groovy. Это очень помогает интуитивно писать работающий код.
• Одновременно вместе со статической, в груви поддерживается динамическая типизация, вместо String a = "a" можно смело писать def a = "a" или даже def map = ['one':1, 'two':2, 'list' = [1,false]]
• Есть замыкания, для которых можно динамически определить контекст исполнения. Те самые блоки android {...} принимают замыкания и потом исполняют их для какого-то объекта.
• Есть интерполяция строк "$a, ${b}", multiline-строки """yep, ${c}""", а обычные java-строки обрамляются одинарными кавычками: 'text'
• Есть подобие extension-методов. В стандартной коллекции языка уже есть методы типа any, every, each, findAll. Лично мне названия методов кажутся непривычными, но главное что они есть.
• Вкусный синтаксический сахар, код становится намного короче и проще. Можно не писать скобки вокруг аргументов функции, для объявления списков и хеш-табличек приятный синтаксис: [a,b,c], [key1: value1, key2: value2]

В общем, почему языки типа Python/Javascript взлетели, а Groovy нет — для меня загадка. Для своего времени, когда в java даже лямбд не было, а альтернативы типа kotlin/scala только-только появлялись или ещё не существовали, Groovy должен был выглядеть реально интересным языком.

Именно гибкость синтаксиса groovy и динамическая типизация позволила в gradle создавать лаконичные DSL.

Сейчас в официальной документации Gradle примеры продублированы на Kotlin, и вроде как планируется переходить на него, но код уже не выглядит таким простым и становится больше похожим на обычный код:

task hello {
    doLast {
        println "hello"
    }
}

vs

tasks.register("hello") {
    doLast {
        println("hello")
    }
}

Впрочем, переименование в Kradle пока не планируется.

Стадии сборки

Их делят на инициализацию, конфигурацию и выполнение.

Идея состоит в том, что gradle собирает ациклический граф зависимостей и вызывает только необходимый минимум их них. Если я правильно понял, стадия инициализации происходит в тот момент, когда исполняется код из build.gradle.

Например, такой:

copy {
   from source
   to dest
}

Или такой:

task epicFail {
   copy{
      from source
      to dest
   }
}

Возможно, это неочевидно, но вышеуказанное будет тормозить инициализацию. Чтобы не заниматься копированием файлов при каждой инициализации, нужно в задаче использоваль блок doLast{...} или doFirst{...} — тогда код завернётся в замыкание и его позовут в момент выполнения задачи.

task properCopy {
    doLast {
        copy {
            from dest
            to source
        }
    }
}

или так

task properCopy(type: Copy) {
    from dest
    to source
}

В старых примерах вместо doLast можно встретить оператор <<, но от него потом отказались из-за неочевидности поведения.

task properCopy << {
    println("files copied")
}

tasks.all

Что забавно, с помощью doLast и doFirst можно навешивать какие-то действия на любые задачи:

tasks.all {
    doFirst {
        println("task $name started")
    }
}

IDE подсказывает, что у tasks есть метод whenTaskAdded(Closure ...), но метод all(Closure ...) работает намного интереснее — замыкание вызывается для всех существующих задач, а так же на новых задачах при их добавлении.

Создадим задачу, которая распечатает зависимости всех задач:

task printDependencies {
    doLast {
        tasks.all {
            println("$name dependsOn $dependsOn")
        }
    }
}

или так:

task printDependencies {
    doLast {
        tasks.all { Task task ->
            println("${task.name} dependsOn ${task.dependsOn}")
        }
    }
}

Если tasks.all{} вызвать во время выполнения (в блоке doLast), то мы увидим все задачи и зависимости.
Если сделать то же самое без doLast (т.е., во время инициализации), то у распечатанных задач может не хватать зависимостей, так как они ещё не были добавлены.

Ах да, зависимости! Если другая задача должна зависеть от результатов выполнения нашей, то стоит добавить зависимость:

anotherTask.dependsOn properCopy

Или даже так:

tasks.all{  task ->
   if (task.name.toLowerCase().contains("debug")) {
       task.dependsOn properCopy
   }
}

inputs, outputs и инкрементальная сборка

Обычная задача будет вызываться каждый раз. Если указать, что задача на основе файла А генерирует файл Б, то gradle будет пропускать задачу, если эти файлы не изменились. Причём gradle проверяет не дату изменения файла, а именно его содержимое.

task generateCode(type: Exec) {
    commandLine "generateCode.sh", "input.txt", "output.java"
    inputs.file "input.txt"
    output.file "output.java"
}

Аналогично можно указать папки, а так же какие-то значения: inputs.property(name, value).

task description

При вызове ./gradlew tasks --all стандартные задачи имеют красивое описание и как-то сгруппированы. Для своих задач это добавляется очень просто:

task hello {
    group "MyCustomGroup"
    description "Prints 'hello'"
    doLast{
        print 'hello'
    }
}

task.enabled

можно «выключить» задачу — тогда её зависимости будут всё равно вызваны, а она сама — нет.

taskName.enabled false

несколько проектов (модулей)

multi-project builds в документации

В основном проекте можно расположить ещё несколько модулей. Например, такое используется в андроид проектах — в рутовом проекте почти ничего нет, в подпроекте включается android плагин. Если захочется добавить новый модуль — можно добавить ещё один, и там, например, тоже подключить android плагин, но использовать другие настройки для него.

Ещё пример: при публикации проекта с помощью jitpack в рутовом проекте описывается, с какими настройками публиковать дочерний модуль, который про факт публикации может даже не подозревать.

Дочерние модули указываются в settings.gradle:

include 'name'

Подробнее про зависимости между проектами можно почитать здесь

buildSrc

Если кода в build.gradle много или он дублируется, его можно вынести в отдельный модуль. Нужна папка с магическим именем buildSrc, в которой можно расположить код на groovy или java. (ну, вернее, в buildSrc/src/main/java/com/smth/ код, тесты можно добавить в buildSrc/src/test). Если хочется что-то ещё, например, написать свою задачу на scala или использовать какие-то зависимости, то прямо в buildSrc надо создать build.gradle и в нём указать нужные зависимости/включить плагины.

К сожалению, с проектом в buildSrc IDE может тупить c подсказками, там придётся писать импорты и классы/задачи оттуда в обычный build.gradle тоже придётся импортировать. Написать import com.smth.Taskname — не сложно, просто надо это помнить и не ломать голову, почему задача из buildSrc не найдена).

По этой причине удобно сначала написать что-то работающее прямо в build.gradle, и только потом переносить код в buildSrc.

Свой тип задачи

Задача наследуется от DefaultTask, в которой есть много-много полей, методов и прочего. Код AbstractTask, от которой унаследована DefaultTask.

Полезные моменты:

• вместо ручного добавления inputs и outputs можно использовать поля и аннотации к ним: @Input, @OutputFile и т.п.
• метод, который будут запускать при выполнении задачи: @TaskAction.
• удобные методы типа copy{from ... , into... } всё ещё можно вызвать, но придётся их явно вызывать для проекта: project.copy{...}

Когда для нашей задачи кто-то в build.gradle пишет

taskName {
    ... //some code
}

у задачи вызывается метод configure(Closure).

Я не уверен, что это правильных подход, но если у задачи есть несколько полей, взаимное состояние которых сложно контролировать геттерами-сеттерами, то кажется вполне удобным переопределить метод следующим образом:

override def configure(Closure closure){
    def result = super().configure(closure)
    // здесь проверить состояние полей/установить что-нибудь
    return result;
}

Причём даже если написать

taskName.fieldName value

то метод configure всё равно будет вызван.

Свой плагин

Подобно задаче, можно написать свой плагин, который будет что-то настраивать или создавать задачи. Например, происходящее в android{...} — полностью заслуга тёмной магии андроид плагина, который вдобавок создаёт целую кучу задач типа app:assembleDevelopDebug на все возможные сочетания flavor/build type/dimenstion. Ничего сложного в написании своего плагина нет, для лучшего понимания можно посмотреть код других плагинов.

Есть ещё третья ступенька — можно код расположить не в buildSrc, а сделать его отдельным проектом. Потом с помощью https://jitpack.io или ещё чего-то опубликовать плагин и подключать его аналогично остальным.

The end

В примерах выше могут быть опечатки и неточности. Пишите в личку или отмечайте с ctrl+enter — исправлю. Конкретные примеры лучше брать из документации, а на эту статью смотреть как на списочек того «как можно делать».

Gradle – Обзор

«Gradle – система автоматизации сборки с открытым исходным кодом»

Ant и Maven достигли значительных успехов на рынке JAVA. Ant был первым инструментом сборки, выпущенным в 2000 году, и он разработан на основе идеи процедурного программирования. Позже он улучшен благодаря возможности принимать плагины и управление зависимостями по сети с помощью Apache-IVY. Основным недостатком является XML как формат для написания сценариев сборки, поскольку иерархическая структура не подходит для процедурного программирования, а XML имеет тенденцию становиться неуправляемо большим.

Maven представлен в 2004 году. Он значительно улучшен по сравнению с ANT. Он меняет свою структуру и продолжает использовать XML для написания спецификаций сборки. Maven опирается на соглашения и может загружать зависимости по сети. Основным преимуществом maven является его жизненный цикл. Следуя одному и тому же жизненному циклу для нескольких проектов непрерывно. Это связано с гибкостью. Maven также сталкивается с некоторыми проблемами в управлении зависимостями. Он плохо обрабатывает конфликты между версиями одной и той же библиотеки, и сложные настраиваемые сценарии сборки на самом деле труднее писать в maven, чем в ANT.

Наконец, в 2012 году появился Gradle. Gradle обладает некоторыми эффективными функциями обоих инструментов.

Особенности Gradle

Ниже приведен список функций, которые предоставляет Gradle.

• Декларативные сборки и сборка по соглашению – Gradle доступен с отдельным предметно-ориентированным языком (DSL) на основе языка Groovy. Gradle предоставляет элементы декларативного языка. Эти элементы также обеспечивают поддержку сборки по соглашению для Java, Groovy, OSGI, Web и Scala.

• Язык программирования на основе зависимостей . Декларативный язык находится на вершине графа задач общего назначения, который вы можете полностью использовать в своей сборке.

• Структурируйте свою сборку – Gradle наконец-то позволяет вам применять общие принципы проектирования к вашей сборке. Это даст вам идеальную структуру для сборки, так что вы сможете разработать хорошо структурированную и легко поддерживаемую, понятную сборку.

• Глубокий API – Используя этот API, он позволяет вам отслеживать и настраивать его конфигурацию и поведение при выполнении.

• Масштабирование Gradle – Gradle может легко увеличить свою производительность, от простых сборок одного проекта до огромных многопроектных сборок предприятия.

• Многопроектные сборки – Gradle поддерживает многопроектные сборки и поддерживает частичные сборки. Если вы строите подпроект, Gradle позаботится о создании всех подпроектов, от которых он зависит.

• Различные способы управления вашими сборками – Gradle поддерживает различные стратегии для управления вашими зависимостями.

• Gradle – это первый инструмент интеграции сборки – Gradle полностью поддерживается для задач ANT, инфраструктура репозитория Maven и lvy для публикации и получения зависимостей. Gradle также предоставляет конвертер для превращения Maven pom.xml в скрипт Gradle.

• Легкость миграции – Gradle может легко адаптироваться к любой вашей структуре. Поэтому вы всегда можете разработать свою сборку Gradle в той же ветке, где вы можете создать живой скрипт.

• Gradle Wrapper – Gradle Wrapper позволяет выполнять сборки Gradle на машинах, где Gradle не установлен. Это полезно для непрерывной интеграции серверов.

• Бесплатный открытый исходный код – Gradle – это проект с открытым исходным кодом, который распространяется под лицензией Apache Software License (ASL).

• Groovy – скрипт сборки Gradle написан на Groovy. Весь дизайн Gradle ориентирован на использование в качестве языка, а не жесткой структуры. А Groovy позволяет вам написать собственный скрипт с некоторыми абстракциями. Весь API Gradle полностью разработан на языке Groovy.

Декларативные сборки и сборка по соглашению – Gradle доступен с отдельным предметно-ориентированным языком (DSL) на основе языка Groovy. Gradle предоставляет элементы декларативного языка. Эти элементы также обеспечивают поддержку сборки по соглашению для Java, Groovy, OSGI, Web и Scala.

Язык программирования на основе зависимостей . Декларативный язык находится на вершине графа задач общего назначения, который вы можете полностью использовать в своей сборке.

Структурируйте свою сборку – Gradle наконец-то позволяет вам применять общие принципы проектирования к вашей сборке. Это даст вам идеальную структуру для сборки, так что вы сможете разработать хорошо структурированную и легко поддерживаемую, понятную сборку.

Глубокий API – Используя этот API, он позволяет вам отслеживать и настраивать его конфигурацию и поведение при выполнении.

Масштабирование Gradle – Gradle может легко увеличить свою производительность, от простых сборок одного проекта до огромных многопроектных сборок предприятия.

Многопроектные сборки – Gradle поддерживает многопроектные сборки и поддерживает частичные сборки. Если вы строите подпроект, Gradle позаботится о создании всех подпроектов, от которых он зависит.

Различные способы управления вашими сборками – Gradle поддерживает различные стратегии для управления вашими зависимостями.

Gradle – это первый инструмент интеграции сборки – Gradle полностью поддерживается для задач ANT, инфраструктура репозитория Maven и lvy для публикации и получения зависимостей. Gradle также предоставляет конвертер для превращения Maven pom.xml в скрипт Gradle.

Легкость миграции – Gradle может легко адаптироваться к любой вашей структуре. Поэтому вы всегда можете разработать свою сборку Gradle в той же ветке, где вы можете создать живой скрипт.

Gradle Wrapper – Gradle Wrapper позволяет выполнять сборки Gradle на машинах, где Gradle не установлен. Это полезно для непрерывной интеграции серверов.

Бесплатный открытый исходный код – Gradle – это проект с открытым исходным кодом, который распространяется под лицензией Apache Software License (ASL).

Groovy – скрипт сборки Gradle написан на Groovy. Весь дизайн Gradle ориентирован на использование в качестве языка, а не жесткой структуры. А Groovy позволяет вам написать собственный скрипт с некоторыми абстракциями. Весь API Gradle полностью разработан на языке Groovy.

Почему Groovy?

Полный API Gradle разработан с использованием языка Groovy. Это преимущество внутреннего DSL над XML. Gradle – это универсальный инструмент для сборки; основное внимание уделяется Java-проектам. В таких проектах члены команды будут очень хорошо знакомы с Java, и лучше, чтобы сборка была максимально прозрачной для всех членов команды.

Такие языки, как Python, Groovy или Ruby, лучше подходят для сборки фреймворка. Почему Groovy был выбран, так это потому, что он предлагает наибольшую прозрачность для людей, использующих Java. Базовый синтаксис Groovy такой же, как Java. Groovy предлагает гораздо больше.

Gradle – Установка

Gradle – это инструмент для сборки, основанный на Java. Есть некоторые предварительные условия, которые должны быть установлены перед установкой рамы Gradle.

Предпосылки

JDK и Groovy являются необходимыми условиями для установки Gradle.

• Gradle требует JDK версии 6 или более поздней версии для установки в вашей системе. Он использует библиотеки JDK, которые установлены и установлены в переменную окружения JAVA_HOME.

• Gradle содержит собственную библиотеку Groovy, поэтому нам не нужно явно устанавливать Groovy. Если он установлен, Gradle игнорирует его.

Gradle требует JDK версии 6 или более поздней версии для установки в вашей системе. Он использует библиотеки JDK, которые установлены и установлены в переменную окружения JAVA_HOME.

Gradle содержит собственную библиотеку Groovy, поэтому нам не нужно явно устанавливать Groovy. Если он установлен, Gradle игнорирует его.

Ниже приведены инструкции по установке Gradle в вашей системе.

Шаг 1 – Проверьте установку JAVA

Прежде всего, вам необходимо установить Java Software Development Kit (SDK) в вашей системе. Чтобы убедиться в этом, выполните команду Java –version на любой платформе, с которой вы работаете.

В винде –

Выполните следующую команду, чтобы проверить установку Java. Я установил JDK 1.8 в моей системе.

C:> java - version

Выход –

java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)

В Linux –

Выполните следующую команду, чтобы проверить установку Java. Я установил JDK 1.8 в моей системе.

$ java - version

Выход –

java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)

Мы предполагаем, что читатели этого руководства установили Java SDK версии 1.8.0_66 в своей системе.

Шаг 2 – Загрузите файл сборки Gradle

Загрузите последнюю версию Gradle по ссылке Download Gradle . На странице ссылок нажмите на ссылку Полный дистрибутив . Этот шаг является общим для любой платформы. Для этого вы получите полный дистрибутивный файл в папку «Загрузки».

Шаг 3 – Настройка среды для Gradle

Настройка среды означает, что мы должны извлечь дистрибутивный файл, скопировать файлы библиотеки в нужное место. Настройка переменных среды GRADLE_HOME и PATH .

Этот шаг зависит от платформы.

В винде –

Извлеките загруженный zip-файл с именем gradle-2.11-all.zip и скопируйте дистрибутивные файлы из каталога Downloads gradle-2.11 в C: gradle location.

После этого добавьте каталоги C: gradle и C: gradle bin в системные переменные GRADLE_HOME и PATH . Следуйте приведенным инструкциям, щелкнув правой кнопкой мыши на моих компьютерах -> выберите свойства -> дополнительные параметры системы -> нажмите переменные среды . Там вы найдете диалоговое окно для создания и редактирования системных переменных. Нажмите на новую кнопку для создания переменной GRADLE_HOME (следуйте скриншоту слева). Нажмите на Edit для редактирования существующей системной переменной Path (следуйте скриншоту справа). Следуйте приведенным ниже скриншотам.

В Linux –

Распакуйте загруженный zip-файл с именем gradle-2.11-all.zip, после чего вы найдете извлеченный файл с именем gradle-2.11 .

Вы можете использовать следующее, чтобы переместить дистрибутивные файлы из Downloads / gradle-2.11 / в / opt / gradle / location. Выполните эту операцию из каталога загрузок.

$ sudo mv gradle-2.11 /opt/gradle

Отредактируйте файл ~ / .bashrc, вставьте в него следующее содержимое и сохраните его.

export ORIENT_HOME = /opt/gradle
export PATH = $PATH:

Выполните следующую команду, чтобы выполнить файл ~ / .bashrc .

$ source ~/.bashrc

Шаг 4: Проверьте установку Gradle

В окнах:

Вы можете выполнить следующую команду в командной строке.

C:> gradle –v

Вывод: там вы найдете версию Gradle.

------------------------------------------------------------
Gradle 2.11
------------------------------------------------------------

Build time: 2016-02-08 07:59:16 UTC
Build number: none
Revision: 584db1c7c90bdd1de1d1c4c51271c665bfcba978
Groovy: 2.4.4

Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.7.0_60 (Oracle Corporation 24.60-b09)
OS: Windows 8.1 6.3 amd64

В Linux:

Вы можете выполнить следующую команду в терминале.

$ gradle –v

Вывод: там вы найдете версию Gradle.

------------------------------------------------------------
Gradle 2.11
------------------------------------------------------------

Build time: 2016-02-08 07:59:16 UTC
Build number: none
Revision: 584db1c7c90bdd1de1d1c4c51271c665bfcba978

Groovy: 2.4.4
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.7.0_60 (Oracle Corporation 24.60-b09)
OS: Linux 3.13.0-74-generic amd64 

Gradle – Build Script

Gradle создает файл сценария для обработки двух вещей; один – это проекты, а другой – задачи . Каждая сборка Gradle представляет один или несколько проектов. Проект представляет собой библиотечный JAR или веб-приложение или может представлять собой ZIP, собранный из JAR, созданных другими проектами. Проще говоря, проект состоит из разных задач. Задача означает часть работы, которую выполняет сборка. Задачей может быть компиляция некоторых классов, создание JAR, генерация Javadoc или публикация некоторых архивов в хранилище.

Gradle использует Groovy для написания скриптов.

Написание сценария сборки

Gradle предоставляет предметно-ориентированный язык (DSL) для описания сборок. Это использует язык Groovy, чтобы упростить описание сборки. Каждый сценарий сборки Gradle кодируется с использованием UTF-8, сохраняется в автономном режиме и называется build.gradle.

build.gradle

Мы описываем задачи и проекты с помощью скрипта Groovy. Вы можете запустить сборку Gradle с помощью команды Gradle. Эта команда ищет файл с именем build.gradle . Взгляните на следующий пример, представляющий небольшой скрипт, который печатает tutorialspoint . Скопируйте и сохраните следующий скрипт в файл с именем build.gradle . Этот скрипт сборки определяет имя задачи hello, которое используется для вывода строки tutorialspoint.

task hello {
   doLast {
      println 'tutorialspoint'
   }
}

Выполните следующую команду в командной строке. Он выполняет вышеуказанный скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

tutorialspoint

Если вы думаете, что задача работает аналогично цели ANT, то это правильно – задача Gradle эквивалентна цели ANT.

Вы можете упростить эту задачу приветствия, указав ярлык (представляет символ << ) для оператора doLast . Если вы добавите этот ярлык к вышеупомянутой задаче, привет, он будет выглядеть как следующий скрипт.

task hello << {
   println 'tutorialspoint'
}

Как и выше, вы можете выполнить приведенный выше скрипт с помощью команды gradle –q hello .

Сценарий Grade в основном использовал два реальных объекта, один из них – объект проекта, а другой – объект сценария.

Объект проекта – каждый сценарий описывает один или несколько проектов. Во время выполнения этот сценарий настраивает объект проекта. Вы можете вызывать некоторые методы и использовать свойства в вашем скрипте сборки, которые делегированы объекту проекта.

Сценарий Объект – Gradle взят код сценария в классы, который реализует интерфейс сценариев, а затем выполняется. Это означает, что все свойства и методы, объявленные интерфейсом скрипта, доступны в вашем скрипте.

В следующей таблице приведен список стандартных свойств проекта . Все эти свойства доступны в вашем скрипте сборки.

Groovy Основы

Скрипты сборки Gradle используют полнофункциональный Groovy API. В качестве стартапа взгляните на следующие примеры.

В следующем примере объясняется, как преобразовать строку в верхний регистр.

Скопируйте и сохраните приведенный ниже код в файл build.gradle .

task upper << {
   String expString = 'TUTORIALS point'
   println "Original: " + expString
   println "Upper case: " + expString.toUpperCase()
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q upper

Выход:

Original: TUTORIALS point
Upper case: TUTORIALS POINT

В следующем примере объясняется, как печатать значение неявного параметра ($ it) 4 раза.

Скопируйте и сохраните следующий код в файл build.gradle .

task count << {
   4.times { 
      print "$it " 
   }
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

$ gradle –q count

Выход:

0 1 2 3

Groovy язык предоставляет множество функций, некоторые из которых обсуждаются ниже.

Groovy JDK Методы

Groovy добавляет множество полезных методов в стандартные классы Java. Например, Iterable API из JDK реализует метод each (), который выполняет итерацию по элементам Iterable Interface.

Скопируйте и сохраните следующий код в файл build.gradle .

task groovyJDK << {
   String myName = "Marc";
   myName.each() { 
      println "${it}" 
   };
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q groovyJDK

Выход:

M
a
r
c

Средства доступа к недвижимости

Вы можете автоматически получить доступ к соответствующим методам получения и установки определенного свойства, указав его ссылку.

Следующий фрагмент определяет синтаксис методов getter и setter свойства buildDir .

// Using a getter method
println project.buildDir
println getProject().getBuildDir()

// Using a setter method
project.buildDir = 'target'
getProject().setBuildDir('target')

Необязательные скобки при вызове метода

Groovy содержит специальную функцию в вызове методов, которая является необязательной скобкой для вызова метода. Эта функция также применима к сценариям Gradle.

Посмотрите на следующий синтаксис. Это определяет метод, вызывающий systemProperty тестового объекта.

test.systemProperty 'some.prop', 'value'
test.systemProperty('some.prop', 'value')

Закрытие как последний параметр метода

Gradle DSL использует замыкания во многих местах. Если последний параметр метода является закрытием, вы можете поместить закрытие после вызова метода.

Следующий фрагмент кода определяет синтаксис, используемый Closures в качестве параметров метода repositories ().

repositories {
   println "in a closure"
}
repositories() { 
   println "in a closure" 
}
repositories({ println "in a closure" })

Импорт по умолчанию

Gradle автоматически добавляет набор операторов импорта в сценарии Gradle. В следующем списке показаны пакеты импорта по умолчанию для скрипта Gradle.

import org.gradle.*
import org.gradle.api.*
import org.gradle.api.artifacts.*
import org.gradle.api.artifacts.cache.*
import org.gradle.api.artifacts.component.*
import org.gradle.api.artifacts.dsl.*
import org.gradle.api.artifacts.ivy.*
import org.gradle.api.artifacts.maven.*
import org.gradle.api.artifacts.query.*
import org.gradle.api.artifacts.repositories.*
import org.gradle.api.artifacts.result.*
import org.gradle.api.component.*
import org.gradle.api.credentials.*
import org.gradle.api.distribution.*
import org.gradle.api.distribution.plugins.*
import org.gradle.api.dsl.*
import org.gradle.api.execution.*
import org.gradle.api.file.*
import org.gradle.api.initialization.*
import org.gradle.api.initialization.dsl.*
import org.gradle.api.invocation.*
import org.gradle.api.java.archives.*
import org.gradle.api.logging.*
import org.gradle.api.plugins.*
import org.gradle.api.plugins.announce.*
import org.gradle.api.plugins.antlr.*
import org.gradle.api.plugins.buildcomparison.gradle.*
import org.gradle.api.plugins.jetty.*
import org.gradle.api.plugins.osgi.*
import org.gradle.api.plugins.quality.*
import org.gradle.api.plugins.scala.*
import org.gradle.api.plugins.sonar.*
import org.gradle.api.plugins.sonar.model.*
import org.gradle.api.publish.*
import org.gradle.api.publish.ivy.*
import org.gradle.api.publish.ivy.plugins.*
import org.gradle.api.publish.ivy.tasks.*
import org.gradle.api.publish.maven.*
import org.gradle.api.publish.maven.plugins.*
import org.gradle.api.publish.maven.tasks.*
import org.gradle.api.publish.plugins.*
import org.gradle.api.reporting.*
import org.gradle.api.reporting.components.*
import org.gradle.api.reporting.dependencies.*
import org.gradle.api.reporting.model.*
import org.gradle.api.reporting.plugins.*
import org.gradle.api.resources.*
import org.gradle.api.specs.*
import org.gradle.api.tasks.*
import org.gradle.api.tasks.ant.*
import org.gradle.api.tasks.application.*
import org.gradle.api.tasks.bundling.*
import org.gradle.api.tasks.compile.*
import org.gradle.api.tasks.diagnostics.*
import org.gradle.api.tasks.incremental.*
import org.gradle.api.tasks.javadoc.*
import org.gradle.api.tasks.scala.*
import org.gradle.api.tasks.testing.*
import org.gradle.api.tasks.testing.junit.*
import org.gradle.api.tasks.testing.testng.*
import org.gradle.api.tasks.util.*
import org.gradle.api.tasks.wrapper.*
import org.gradle.authentication.*
import org.gradle.authentication.http.*
import org.gradle.buildinit.plugins.*
import org.gradle.buildinit.tasks.*
import org.gradle.external.javadoc.*
import org.gradle.ide.cdt.*
import org.gradle.ide.cdt.tasks.*
import org.gradle.ide.visualstudio.*
import org.gradle.ide.visualstudio.plugins.*
import org.gradle.ide.visualstudio.tasks.*
import org.gradle.ivy.*
import org.gradle.jvm.*
import org.gradle.jvm.application.scripts.*
import org.gradle.jvm.application.tasks.*
import org.gradle.jvm.platform.*
import org.gradle.jvm.plugins.*
import org.gradle.jvm.tasks.*
import org.gradle.jvm.tasks.api.*
import org.gradle.jvm.test.*
import org.gradle.jvm.toolchain.*
import org.gradle.language.assembler.*
import org.gradle.language.assembler.plugins.*
import org.gradle.language.assembler.tasks.*
import org.gradle.language.base.*
import org.gradle.language.base.artifact.*
import org.gradle.language.base.plugins.*
import org.gradle.language.base.sources.*
import org.gradle.language.c.*
import org.gradle.language.c.plugins.*
import org.gradle.language.c.tasks.*
import org.gradle.language.coffeescript.*
import org.gradle.language.cpp.*
import org.gradle.language.cpp.plugins.*
import org.gradle.language.cpp.tasks.*
import org.gradle.language.java.*
import org.gradle.language.java.artifact.*
import org.gradle.language.java.plugins.*
import org.gradle.language.java.tasks.*
import org.gradle.language.javascript.*
import org.gradle.language.jvm.*
import org.gradle.language.jvm.plugins.*
import org.gradle.language.jvm.tasks.*
import org.gradle.language.nativeplatform.*
import org.gradle.language.nativeplatform.tasks.*
import org.gradle.language.objectivec.*
import org.gradle.language.objectivec.plugins.*
import org.gradle.language.objectivec.tasks.*
import org.gradle.language.objectivecpp.*
import org.gradle.language.objectivecpp.plugins.*
import org.gradle.language.objectivecpp.tasks.*
import org.gradle.language.rc.*
import org.gradle.language.rc.plugins.*
import org.gradle.language.rc.tasks.*
import org.gradle.language.routes.*
import org.gradle.language.scala.*
import org.gradle.language.scala.plugins.*
import org.gradle.language.scala.tasks.*
import org.gradle.language.scala.toolchain.*
import org.gradle.language.twirl.*
import org.gradle.maven.*
import org.gradle.model.*
import org.gradle.nativeplatform.*
import org.gradle.nativeplatform.platform.*
import org.gradle.nativeplatform.plugins.*
import org.gradle.nativeplatform.tasks.*
import org.gradle.nativeplatform.test.*
import org.gradle.nativeplatform.test.cunit.*
import org.gradle.nativeplatform.test.cunit.plugins.*
import org.gradle.nativeplatform.test.cunit.tasks.*
import org.gradle.nativeplatform.test.googletest.*
import org.gradle.nativeplatform.test.googletest.plugins.*
import org.gradle.nativeplatform.test.plugins.*
import org.gradle.nativeplatform.test.tasks.*
import org.gradle.nativeplatform.toolchain.*
import org.gradle.nativeplatform.toolchain.plugins.*
import org.gradle.platform.base.*
import org.gradle.platform.base.binary
import org.gradle.platform.base.component.*
import org.gradle.platform.base.plugins.*
import org.gradle.platform.base.test.*
import org.gradle.play.*
import org.gradle.play.distribution.*
import org.gradle.play.platform.*
import org.gradle.play.plugins.*
import org.gradle.play.tasks.*
import org.gradle.play.toolchain.*
import org.gradle.plugin.use.*
import org.gradle.plugins.ear.*
import org.gradle.plugins.ear.descriptor.*
import org.gradle.plugins.ide.api.*
import org.gradle.plugins.ide.eclipse.*
import org.gradle.plugins.ide.idea.*
import org.gradle.plugins.javascript.base.*
import org.gradle.plugins.javascript.coffeescript.*
import org.gradle.plugins.javascript.envjs.*
import org.gradle.plugins.javascript.envjs.browser.*
import org.gradle.plugins.javascript.envjs.http.*
import org.gradle.plugins.javascript.envjs.http.simple.*
import org.gradle.plugins.javascript.jshint.*
import org.gradle.plugins.javascript.rhino.*
import org.gradle.plugins.javascript.rhino.worker.*
import org.gradle.plugins.signing.*
import org.gradle.plugins.signing.signatory.*
import org.gradle.plugins.signing.signatory.pgp.*
import org.gradle.plugins.signing.type.*
import org.gradle.plugins.signing.type.pgp.*
import org.gradle.process.*
import org.gradle.sonar.runner.*
import org.gradle.sonar.runner.plugins.*
import org.gradle.sonar.runner.tasks.*
import org.gradle.testing.jacoco.plugins.*
import org.gradle.testing.jacoco.tasks.*
import org.gradle.testkit.runner.*
import org.gradle.util.*

Gradle – Задачи

Скрипт сборки Gradle описывает один или несколько проектов. Каждый проект состоит из разных задач. Задача – это часть работы, которую выполняет сборка. Задачей может быть компиляция некоторых классов, хранение файлов классов в отдельной целевой папке, создание JAR, генерация Javadoc или публикация некоторых достижений в репозитории.

В этой главе объясняется, что такое задача, а также как ее создать и выполнить.

Определение задач

Задача – это ключевое слово, которое используется для определения задачи в сценарии сборки. Посмотрите на следующий пример, который представляет задачу с именем hello, которая печатает tutorialspoint . Скопируйте и сохраните следующий скрипт в файл с именем build.gradle . Этот сценарий сборки определяет имя задачи hello, которое используется для печати строки tutorialspoint.

task hello {
   doLast {
      println 'tutorialspoint'
   }
}

Выполните следующую команду в командной строке. Он выполняет вышеуказанный скрипт. Вы должны выполнить это там, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

tutorialspoint

Вы можете упростить эту задачу приветствия, указав ярлык (представляет символ << ) для оператора doLast . Если вы добавите этот ярлык к вышеупомянутой задаче, привет, он будет выглядеть как следующий скрипт.

task hello << {
   println 'tutorialspoint'
}

Вы можете выполнить приведенный выше скрипт с помощью команды gradle –q hello .

Вот несколько вариантов определения задачи, посмотрите на нее. В следующем примере определяется задача hello .

Скопируйте и сохраните следующий код в файл build.gradle .

task (hello) << {
   println "tutorialspoint"
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

tutorialspoint

Вы также можете использовать строки для имен задач. Взгляните на тот же самый привет пример. Здесь мы будем использовать String как задачу.

Скопируйте и сохраните следующий код в файл build.gradle .

task('hello') << {
   println "tutorialspoint"
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

tutorialspoint

Вы также можете использовать альтернативный синтаксис для определения задачи. Это использует метод create () для определения задачи. Взгляните на тот же самый привет пример, приведенный ниже.

Скопируйте и сохраните приведенный ниже код в файл build.gradle .

tasks.create(name: 'hello') << {
   println "tutorialspoint"
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

tutorialspoint

Поиск задач

Если вы хотите найти задачи, которые вы определили в файле сборки, вам нужно использовать соответствующие стандартные свойства проекта. Это означает, что каждая задача доступна как свойство проекта, используя имя задачи в качестве имени свойства.

Взгляните на следующий код, который обращается к задачам как к свойствам.

Скопируйте и сохраните приведенный ниже код в файл build.gradle .

task hello

println hello.name
println project.hello.name

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

hello
hello

Вы также можете использовать все свойства через коллекцию задач.

Скопируйте и сохраните следующий код в файл build.gradle .

task hello

println tasks.hello.name
println tasks['hello'].name

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

hello
hello

Вы также можете получить доступ к пути задачи, используя задачи. Для этого вы можете вызвать метод getByPath () с именем задачи, либо относительным путем, либо абсолютным путем.

Скопируйте и сохраните приведенный ниже код в файл build.gradle .

project(':projectA') {
   task hello
}
task hello

println tasks.getByPath('hello').path
println tasks.getByPath(':hello').path
println tasks.getByPath('projectA:hello').path
println tasks.getByPath(':projectA:hello').path

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle.

C:> gradle –q hello

Выход:

:hello
:hello
:projectA:hello
:projectA:hello

Добавление зависимостей к задачам

Вы можете сделать задачу зависимой от другой задачи, что означает, что когда одна задача выполнена, тогда запускается только другая задача. Каждое задание отличается от имени задания. Коллекция имен задач называется ее коллекцией задач. Чтобы сослаться на задачу в другом проекте, вы должны использовать путь к проекту в качестве префикса к соответствующему имени задачи.

Следующий пример, который добавляет зависимость из taskX в taskY.

Скопируйте и сохраните приведенный ниже код в файл build.gradle . Посмотрите на следующий код.

task taskX << {
   println 'taskX'
}
task taskY(dependsOn: 'taskX') << {
   println "taskY"
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle .

C:> gradle –q taskY

Выход:

taskX
taskY

Приведенный выше пример добавляет зависимость от задачи, используя ее имена. Существует еще один способ достижения зависимости задачи, который заключается в определении зависимости с помощью объекта Task.

Давайте возьмем тот же пример зависимости задачиY от задачи X, но мы используем объекты задачи вместо имен ссылок на задачи.

Скопируйте и сохраните следующий код в файл build.gradle .

task taskY << {
   println 'taskY'
}
task taskX << {
   println 'taskX'
}
taskY.dependsOn taskX

Выполните следующую команду в командной строке. Вы должны выполнить это там, где хранится файл build.gradle.

C:> gradle –q taskY

Выход:

taskX
taskY

Приведенный выше пример добавляет зависимость от задачи, используя ее имена. Есть еще один способ достижения зависимости задачи – определить зависимость с помощью объекта Task.

Здесь мы берем тот же пример, что taskY зависит от taskX, но мы используем объекты задачи вместо имен ссылок на задачи. Взгляните на это.

Скопируйте и сохраните приведенный ниже код в файл build.gradle . Посмотрите на следующий код.

task taskX << {
   println 'taskX'
}
taskX.dependsOn {
   tasks.findAll { 
      task → task.name.startsWith('lib') 
   }
}
task lib1 << {
   println 'lib1'
}
task lib2 << {
   println 'lib2'
}
task notALib << {
   println 'notALib'
}

Выполните следующую команду в командной строке. Он выполняет приведенный выше скрипт. Вы должны выполнить это, где хранится файл build.gradle .

C:> gradle –q taskX

Выход:

lib1
lib2
taskX

Добавление описания к задаче

Вы можете добавить описание к вашей задаче. Это описание отображается при выполнении задач Gradle . Это возможно с помощью ключевого слова description.

Скопируйте и сохраните следующий код в файл build.gradle . Посмотрите на следующий код.

task copy(type: Copy) {
   description 'Copies the resource directory to the target directory.'
   from 'resources'
   into 'target'
   include('**/*.txt', '**/*.xml', '**/*.properties')
   println("description applied")
}

Выполните следующую команду в командной строке. Вы должны выполнить это там, где хранится файл build.gradle.

C:> gradle –q copy

Если команда выполнена успешно, вы получите следующий вывод.

description applied

Пропуск задач

Пропуск задач может быть выполнен путем передачи предиката замыкания. Это возможно только в том случае, если метод задачи или замыкание генерируют исключение StopExecutionException до выполнения фактической работы задачи.

Скопируйте и сохраните следующий код в файл build.gradle .

task eclipse << {
   println 'Hello Eclipse'
}

// #1st approach - closure returning true, if the task should be executed, false if not.
eclipse.onlyIf {
   project.hasProperty('usingEclipse')
}

// #2nd approach - alternatively throw an StopExecutionException() like this
eclipse.doFirst {
   if(!usingEclipse) {
      throw new StopExecutionException()
   }
}

Выполните следующую команду в командной строке. Вы должны выполнить это там, где хранится файл build.gradle.

C:> gradle –q eclipse

Структура задачи

Gradle имеет разные фазы при работе с заданиями. Прежде всего, это фаза конфигурации, на которой выполняется код, который указывается непосредственно при закрытии задачи. Блок конфигурации выполняется для каждой доступной задачи, а не только для тех задач, которые впоследствии фактически выполняются.

После фазы конфигурирования фаза выполнения запускает код внутри замыканий doFirst или doLast тех задач, которые фактически выполняются.

Gradle – управление зависимостями

Скрипт сборки Gradle определяет процесс сборки проектов; каждый проект содержит некоторые зависимости и некоторые публикации. Зависимости означают вещи, которые поддерживают создание вашего проекта, такие как требуемый файл JAR из других проектов и внешние JAR, такие как JDBC JAR или Eh-cache JAR в пути к классам. Публикации означают результаты проекта, такие как файлы тестовых классов и файлы сборки, такие как файлы war.

Все большинство всех проектов не являются самостоятельными. Им нужны файлы, созданные другими проектами для компиляции и тестирования исходных файлов. Например, чтобы использовать Hibernate в проекте, вам нужно включить некоторые JAR-файлы Hibernate в classpath. Gradle использует специальный скрипт для определения зависимостей, которые необходимо загрузить.

Gradle позаботится о создании и публикации результатов где-нибудь. Публикация основана на задаче, которую вы определяете. Возможно, вы захотите скопировать файлы в локальный каталог или загрузить их в удаленный репозиторий Maven или lvy, или вы можете использовать файлы из другого проекта в той же многопроектной сборке. Мы можем назвать процесс публикации задачи публикацией.

Объявление ваших зависимостей

Конфигурация зависимостей – это не что иное, как набор множеств зависимостей. Вы можете использовать эту функцию для объявления внешних зависимостей средствами, которые вы хотите загрузить из Интернета. Это определяет различные стандарты, такие как следующие.

apply plugin: 'java'

repositories {
   mavenCentral()
}

dependencies {
   compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
   testCompile group: 'junit', name: 'junit', version: '4.+'
}

Конфигурации зависимостей

Конфигурация зависимостей – это не что иное, как набор зависимостей. Вы можете использовать эту функцию для объявления внешних зависимостей, которые вы хотите загрузить из Интернета. Это определяет следующие различные стандартные конфигурации.

• Компилировать – зависимости, необходимые для компиляции производственного источника проекта.

• Runtime – зависимости, необходимые производственным классам во время выполнения. По умолчанию также включает зависимости времени компиляции.

• Тестовая компиляция – зависимости, необходимые для компиляции исходного кода проекта. По умолчанию он включает скомпилированные производственные классы и зависимости времени компиляции.

• Test Runtime – зависимости, необходимые для запуска тестов. По умолчанию он включает зависимости времени выполнения и тестовой компиляции.

Компилировать – зависимости, необходимые для компиляции производственного источника проекта.

Runtime – зависимости, необходимые производственным классам во время выполнения. По умолчанию также включает зависимости времени компиляции.

Тестовая компиляция – зависимости, необходимые для компиляции исходного кода проекта. По умолчанию он включает скомпилированные производственные классы и зависимости времени компиляции.

Test Runtime – зависимости, необходимые для запуска тестов. По умолчанию он включает зависимости времени выполнения и тестовой компиляции.

Внешние зависимости

Внешние зависимости относятся к типу зависимостей. Это зависимость от некоторых файлов, созданных вне текущей сборки и хранящихся в каком-либо репозитории, таком как Maven central, или в корпоративном репозитории Maven или lvy, или в каталоге в локальной файловой системе.

Следующий фрагмент кода предназначен для определения внешней зависимости. Используйте этот код в файле build.gradle .

dependencies {
   compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
}

Внешняя зависимость объявляет внешние зависимости, а форма ярлыка выглядит как «группа: имя: версия».

Хранилища

При добавлении внешних зависимостей. Gradle ищет их в хранилище. Репозиторий – это просто набор файлов, упорядоченный по группам, именам и версиям. По умолчанию Gradle не определяет никаких репозиториев. Мы должны определить хотя бы одно хранилище явно. Следующий фрагмент кода определяет, как определить хранилище maven. Используйте этот код в файле build.gradle .

repositories {
   mavenCentral()
}

Следующий код предназначен для определения удаленного Maven. Используйте этот код в файле build.gradle .

repositories {
   maven {
      url "http://repo.mycompany.com/maven2"
   }
}

Издательские артефакты

Конфигурации зависимостей также используются для публикации файлов. Эти опубликованные файлы называются артефактами. Обычно мы используем плагины для определения артефактов. Тем не менее, вам нужно указать Gradle, где публиковать артефакты. Вы можете достичь этого, прикрепив репозитории к задаче загрузки архивов. Взгляните на следующий синтаксис публикации репозитория Maven. При выполнении Gradle создаст и загрузит Pom.xml в соответствии с требованиями проекта. Используйте этот код в файле build.gradle .

apply plugin: 'maven'

uploadArchives {
   repositories {
      mavenDeployer {
         repository(url: "file://localhost/tmp/myRepo/")
      }
   }
}

Gradle – Плагины

Плагин – это не что иное, как набор задач, почти все полезные задачи, такие как компиляция задач, настройка объектов домена, настройка исходных файлов и т. Д., Выполняются плагинами. Применение плагина к проекту означает, что он позволяет расширять возможности проекта. Плагины могут делать такие вещи, как –

• Расширьте базовую модель Gradle (например, добавьте новые элементы DSL, которые можно настроить).
• Настройте проект в соответствии с преобразованиями (например, добавьте новые задачи или настройте разумные значения по умолчанию).
• Применить конкретную конфигурацию (например, добавить организационные репозитории или обеспечить соблюдение стандартов).

Типы плагинов

В Gradle есть два типа плагинов: плагины для скриптов и бинарные плагины. Плагины скриптов – это дополнительный скрипт сборки, который дает декларативный подход к манипулированию сборкой. Обычно это используется в сборке. Бинарные плагины – это классы, которые реализуют интерфейс плагина и применяют программный подход к управлению сборкой. Бинарные плагины могут находиться со скриптом сборки, с иерархией проекта или внешне в JAR плагина.

Применение плагинов

Метод API Project.apply () используется для применения определенного плагина. Вы можете использовать один и тот же плагин несколько раз. Существует два типа плагинов: один – плагин скрипта, а второй – бинарный плагин.

Скриптовые плагины

Плагины сценариев могут быть применены из сценария в локальной файловой системе или в удаленном месте. Расположение файловой системы относится к каталогу проекта, в то время как расположение удаленного сценария указывает URL-адрес HTTP. Взгляните на следующий фрагмент кода. Он используется для применения плагина other.gradle к сценарию сборки. Используйте этот код в файле build.gradle .

apply from: 'other.gradle'

Бинарные плагины

Каждый плагин идентифицируется по идентификатору плагина, так как некоторые основные плагины используют короткие имена для его применения, а некоторые плагины сообщества используют полное имя для идентификатора плагина. Некоторое время это позволяет указать класс плагина.

Взгляните на следующий фрагмент кода. Он показывает, как применить плагин Java, используя его тип. Используйте этот код в файле build.gradle .

apply plugin: JavaPlugin

Посмотрите на следующий код для применения основного плагина, используя короткое имя. Используйте этот код в файле build.gradle .

plugins {
   id 'java'
}

Взгляните на следующий код для применения плагина сообщества с использованием короткого имени. Используйте этот код в файле build.gradle .

plugins {
   id "com.jfrog.bintray" version "0.4.1"
}

Написание пользовательских плагинов

При создании пользовательского плагина вам необходимо написать реализацию плагина. Gradle создает плагин и вызывает экземпляр плагина с помощью метода Plugin.apply (). Следующий пример содержит плагин приветствия, который добавляет задачу приветствия в проект. Посмотрите на следующий код. Используйте этот код в файле build.gradle .

apply plugin: GreetingPlugin

class GreetingPlugin implements Plugin<Project> {
   void apply(Project project) {
      project.task('hello') << {
         println "Hello from the GreetingPlugin"
      }
   }
}

Используйте следующий код для выполнения вышеуказанного сценария.

C:> gradle -q hello

Выход:

Hello from the GreetingPlugin

Получение информации от сборки

Большинству плагинов требуется поддержка конфигурации из скрипта сборки. У проекта Gradle есть связанный объект ExtensionContainer, который помогает отслеживать все настройки и свойства, передаваемые плагинам.

Давайте добавим простой объект расширения в проект. Здесь мы добавляем объект расширения приветствия в проект, который позволяет настроить приветствие. Используйте этот код в файле build.gradle .

apply plugin: GreetingPlugin

greeting.message = 'Hi from Gradle'

class GreetingPlugin implements Plugin<Project> {
   void apply(Project project) {
      // Add the 'greeting' extension object
      project.extensions.create("greeting", GreetingPluginExtension)
		
      // Add a task that uses the configuration
      project.task('hello') << {
         println project.greeting.message
      }
   }
}

class GreetingPluginExtension {
   def String message = 'Hello from GreetingPlugin'
}

Используйте следующий код для выполнения вышеуказанного сценария.

C:> gradle -q hello

Выход:

Hi from Gradle

В этом примере GreetingPlugin – это простой старый объект Groovy с полем с именем message. Объект расширения добавляется в список плагинов с именем приветствия. Затем этот объект становится доступным как свойство проекта с тем же именем, что и у объекта расширения.

Gradle добавляет закрытие конфигурации для каждого объекта расширения, поэтому вы можете сгруппировать настройки вместе. Посмотрите на следующий код. Используйте этот код в файле build.gradle .

apply plugin: GreetingPlugin

greeting {
   message = 'Hi'
   greeter = 'Gradle'
}

class GreetingPlugin implements Plugin<Project> {
   void apply(Project project) {
      project.extensions.create("greeting", GreetingPluginExtension)
		
      project.task('hello') << {
         println "${project.greeting.message} from ${project.greeting.greeter}"
      }
   }
}

class GreetingPluginExtension {
   String message
   String greeter
}

Используйте следующий код для выполнения вышеуказанного сценария.

C:> gradle -q hello

Выход:

Hello from Gradle

Стандартные плагины Gradle

Существуют различные плагины, которые включены в дистрибутив Gradle.

Языковые плагины

Эти плагины добавляют поддержку различных языков, которые могут быть скомпилированы и выполнены в JVM.

Инкубация языковых плагинов

Эти плагины добавляют поддержку различных языков.

Gradle – Запуск сборки

Gradle предоставляет командную строку для выполнения сценария сборки. Он может выполнять более одной задачи одновременно. В этой главе объясняется, как выполнять несколько задач с использованием разных параметров.

Выполнение нескольких задач

Вы можете выполнить несколько задач из одного файла сборки. Gradle может обработать этот файл сборки с помощью команды gradle . Эта команда скомпилирует каждую задачу в порядке их перечисления и выполнит каждую задачу вместе с зависимостями, используя различные параметры.

Пример – есть четыре задачи – задача1, задача2, задача3 и задача4. Задача 3 и задача 4 зависят от задачи 1 и задачи 2. Посмотрите на следующую диаграмму.

В приведенном выше 4 задачи зависят друг от друга и представлены символом стрелки. Посмотрите на следующий код. Копировать можно вставить в файл build.gradle .

task task1 << {
   println 'compiling source'
}

task task2(dependsOn: task1) << {
   println 'compiling unit tests'
}

task task3(dependsOn: [task1, task2]) << {
   println 'running unit tests'
}

task task4(dependsOn: [task1, task3]) << {
   println 'building the distribution'
}

Вы можете использовать следующий код для компиляции и выполнения вышеуказанной задачи.

C:> gradle task4 test

Выход:

:task1
compiling source
:task2
compiling unit tests
:task3
running unit tests
:task4
building the distribution

BUILD SUCCESSFUL

Total time: 1 secs

Исключая задачи

При исключении задачи из выполнения вы можете использовать опцию –x вместе с командой gradle и указать имя задачи, которое вы хотите исключить.

Используйте следующую команду, чтобы исключить task4 из приведенного выше сценария.

C:> gradle task4 -x test

Выход:

:task1
compiling source
:task4
building the distribution

BUILD SUCCESSFUL

Total time: 1 secs

Продолжение сборки, когда происходит сбой

Gradle прервет выполнение и завершит сборку сразу после сбоя любой задачи. Вы можете продолжить выполнение даже в случае сбоя. Для этого вы должны использовать опцию –continue с командой gradle. Он обрабатывает каждую задачу отдельно вместе с их зависимостями. И главное – он будет отлавливать каждую обнаруженную ошибку и сообщать об окончании сборки. Предположим, что если задача не выполнена, то последующие зависимые задачи также не будут выполнены.

Выбор сборки для выполнения

Когда вы запускаете команду gradle, она ищет файл сборки в текущем каталоге. Вы можете использовать опцию –b, чтобы выбрать конкретный файл сборки вместе с абсолютным путем. В следующем примере выбирается проект hello из файла myproject.gradle, который находится в подкаталоге / посмотрите на него.

task hello << {
   println "using build file '$buildFile.name' in '$buildFile.parentFile.name'."
}

Вы можете использовать следующую команду для выполнения вышеуказанного скрипта.

C:> gradle -q -b subdir/myproject.gradle hello

Выход:

using build file 'myproject.gradle' in 'subdir'.

Получение информации о сборке

Gradle предоставляет несколько встроенных задач для получения подробной информации о задаче и проекте. Это может быть полезно для понимания структуры и зависимостей вашей сборки и для устранения проблем. Вы можете использовать плагин отчетов проекта, чтобы добавить задачи в ваш проект, который будет генерировать эти отчеты.

Листинг проектов

Вы можете перечислить иерархию проектов выбранного проекта и его подпроектов с помощью команды gradle –q projects . Вот пример, используйте следующую команду, чтобы получить список всех проектов в файле сборки.

C:> gradle -q projects

Выход:

------------------------------------------------------------
Root project
------------------------------------------------------------

Root project 'projectReports'
+--- Project ':api' - The shared API for the application
--- Project ':webapp' - The Web application implementation

To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :api:tasks

Отчет показывает описание каждого проекта, если он указан. Вы можете использовать следующую команду, чтобы указать описание. Вставьте его в файл build.gradle .

description = 'The shared API for the application'

Листинг Задачи

Вы можете перечислить все задачи, которые принадлежат нескольким проектам, используя следующую команду.

C:> gradle -q tasks

Выход:

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Default tasks: dists

Build tasks
-----------
clean - Deletes the build directory (build)
dists - Builds the distribution
libs - Builds the JAR

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'projectReports'.
components - Displays the components produced by root project 'projectReports'. [incubating]
dependencies - Displays all dependencies declared in root project 'projectReports'.
dependencyInsight - Displays the insight into a specific dependency in root project 'projectReports'.
help - Displays a help message.
model - Displays the configuration model of root project 'projectReports'. [incubating]
projects - Displays the sub-projects of root project 'projectReports'.
properties - Displays the properties of root project 'projectReports'.
tasks - Displays the tasks runnable from root project 'projectReports' 
   (some of the displayed tasks may belong to subprojects).

To see all tasks and more detail, run gradle tasks --all

To see more detail about a task, run gradle help --task <task>

Вы можете использовать следующую команду для отображения информации обо всех задачах.

C:> gradle -q tasks --all

Выход:

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Default tasks: dists

Build tasks
-----------
clean - Deletes the build directory (build)
api:clean - Deletes the build directory (build)
webapp:clean - Deletes the build directory (build)
dists - Builds the distribution [api:libs, webapp:libs]
   docs - Builds the documentation
api:libs - Builds the JAR
   api:compile - Compiles the source files
webapp:libs - Builds the JAR [api:libs]
   webapp:compile - Compiles the source files

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'projectReports'.
api:buildEnvironment - Displays all buildscript dependencies declared in project ':api'.
webapp:buildEnvironment - Displays all buildscript dependencies declared in project ':webapp'.
components - Displays the components produced by root project 'projectReports'. [incubating]
api:components - Displays the components produced by project ':api'. [incubating]
webapp:components - Displays the components produced by project ':webapp'. [incubating]
dependencies - Displays all dependencies declared in root project 'projectReports'.
api:dependencies - Displays all dependencies declared in project ':api'.
webapp:dependencies - Displays all dependencies declared in project ':webapp'.
dependencyInsight - Displays the insight into a specific dependency in root project 'projectReports'.
api:dependencyInsight - Displays the insight into a specific dependency in project ':api'.
webapp:dependencyInsight - Displays the insight into a specific dependency in project ':webapp'.
help - Displays a help message.
api:help - Displays a help message.
webapp:help - Displays a help message.
model - Displays the configuration model of root project 'projectReports'. [incubating]
api:model - Displays the configuration model of project ':api'. [incubating]
webapp:model - Displays the configuration model of project ':webapp'. [incubating]
projects - Displays the sub-projects of root project 'projectReports'.
api:projects - Displays the sub-projects of project ':api'.
webapp:projects - Displays the sub-projects of project ':webapp'.
properties - Displays the properties of root project 'projectReports'.
api:properties - Displays the properties of project ':api'.
webapp:properties - Displays the properties of project ':webapp'.
tasks - Displays the tasks runnable from root project 'projectReports' 
   (some of the displayed tasks may belong to subprojects).
api:tasks - Displays the tasks runnable from project ':api'.
webapp:tasks - Displays the tasks runnable from project ':webapp'.

Вот некоторые списки команд в таблице описания различных опций.

Gradle – Создайте проект JAVA

В этой главе рассказывается о том, как собрать проект Java с помощью файла сборки Gradle.

Прежде всего, мы должны добавить плагин Java в скрипт сборки, потому что он предоставляет задачи для компиляции исходного кода Java, запуска модульных тестов, создания Javadoc и создания файла JAR. Используйте следующую строку в файле build.gradle .

apply plugin: 'java'

Макет проекта Java по умолчанию

Когда вы добавляете плагин в свою сборку, он предполагает определенную настройку вашего Java-проекта (аналогично Maven). взгляните на следующую структуру каталогов.

• src / main / java содержит исходный код Java
• src / test / java содержит тесты Java

Если вы выполните эту настройку, следующий файл сборки будет достаточен для компиляции, тестирования и компоновки проекта Java.

Чтобы начать сборку, введите следующую команду в командной строке.

C:> gradle build

Исходные наборы могут использоваться для указания другой структуры проекта. Например, источники хранятся в папке src, а не в src / main / java . Взгляните на следующую структуру каталогов.

apply plugin: 'java'
sourceSets {
   main {
      java {
         srcDir 'src'
      }
   }
	
   test {
      java {
         srcDir 'test'
      }
   }
}

Выполнение задачи init

Gradle еще не поддерживает несколько шаблонов проектов. Но он предлагает задачу инициализации для создания структуры нового проекта Gradle. Без дополнительных параметров эта задача создает проект Gradle, который содержит файлы-оболочки Gradle, файлы build.gradle и settings.gradle .

При добавлении параметра –type с java-библиотекой в качестве значения создается структура проекта java, и файл build.gradle содержит определенный шаблон Java с Junit. Посмотрите на следующий код для файла build.gradle .

apply plugin: 'java'

repositories {
   jcenter()
}

dependencies {
   compile 'org.slf4j:slf4j-api:1.7.12'
   testCompile 'junit:junit:4.12'
}

В разделе репозитории он определяет, где найти зависимости. Jcenter для разрешения ваших зависимостей. Раздел «Зависимости» предназначен для предоставления информации о внешних зависимостях.

Указание версии Java

Обычно проект Java имеет версию и целевую JRE, на которой он компилируется. Свойство version и sourceCompatibility можно установить в файле build.gradle .

version = 0.1.0
sourceCompatibility = 1.8

Если артефакт является исполняемым Java-приложением, файл MANIFEST.MF должен знать класс с методом main.

apply plugin: 'java'

jar {
   manifest {
      attributes 'Main-Class': 'com.example.main.Application'
   }
}

Пример:

Создайте структуру каталогов, как показано на скриншоте ниже.

Скопируйте приведенный ниже Java-код в файл App.java и сохраните его в каталоге consumerbanking src main java com bank .

package com.bank;

/**
* Hello world!
*
*/

public class App {
   public static void main( String[] args ){
      System.out.println( "Hello World!" );
   }
}

Скопируйте приведенный ниже Java-код в файл AppTset.java и сохраните его в каталоге customerbanking src test java com bank .

package com.bank;

/**
* Hello world!
*
*/

public class App{
   public static void main( String[] args ){
      System.out.println( "Hello World!" );
   }
}

Скопируйте приведенный ниже код в файл build.gradle и поместите его в каталог consumerbanking .

apply plugin: 'java'

repositories {
   jcenter()
}

dependencies {
   compile 'org.slf4j:slf4j-api:1.7.12'
   testCompile 'junit:junit:4.12'
}

jar {
   manifest {
      attributes 'Main-Class': 'com.example.main.Application'
   }
}

Для компиляции и выполнения вышеуказанного скрипта используйте приведенные ниже команды.

consumerbanking> gradle tasks
consumerbanking> gradle assemble
consumerbanking> gradle build

Проверьте все файлы классов в соответствующих каталогах и проверьте папку consumerbanking build lib на наличие файла consumerbanking.jar .

Gradle – построить Groovy проект

В этой главе объясняется, как скомпилировать и выполнить проект Groovy с использованием файла build.gradle .

Groovy Плагин

Подключаемый модуль Groovy для Gradle расширяет подключаемый модуль Java и предоставляет задачи для программ Groovy. Вы можете использовать следующую строку для применения Groovy плагин.

apply plugin: 'groovy'

Полный файл сценария сборки выглядит следующим образом. Скопируйте следующий код в файл build.gradle .

apply plugin: 'groovy'

repositories {
   mavenCentral()
}

dependencies {
   compile 'org.codehaus.groovy:groovy-all:2.4.5'
   testCompile 'junit:junit:4.12'
}

Вы можете использовать следующую команду для выполнения сценария сборки.

gradle build

Макет проекта Groovy по умолчанию

Плагин Groovy предполагает определенную настройку вашего проекта Groovy.

• src / main / groovy содержит исходный код Groovy
• src / test / groovy содержит Groovy тесты
• src / main / java содержит исходный код Java
• src / test / java содержит тесты Java

Проверьте соответствующий каталог, где находится файл build.gradle для папки сборки.

Gradle – Тестирование

Тестовое задание автоматически обнаруживает и выполняет все модульные тесты в наборе исходных текстов теста. Он также генерирует отчет после завершения теста. JUnit и TestNG являются поддерживаемыми API.

Тестовое задание предоставляет метод Test.getDebug (), который можно настроить на запуск, чтобы заставить JVM ожидать отладчик. Прежде чем приступить к выполнению, он устанавливает пост отладчика на 5005 .

Обнаружение теста

Тестовое задание определяет, какие классы являются тестовыми, проверяя скомпилированные тестовые классы. По умолчанию он сканирует все файлы .class. Вы можете установить пользовательские включения / исключения, только те классы будут сканироваться. В зависимости от используемой среды тестирования (JUnit / TestNG) для определения класса теста используются разные критерии.

При использовании JUnit мы сканируем тестовые классы JUnit 3 и 4. Если какой-либо из следующих критериев соответствует, класс считается тестовым классом JUnit –

• Класс или суперкласс расширяет TestCase или GroovyTestCase
• Класс или суперкласс аннотируются @RunWith
• Класс или суперкласс содержат метод, аннотированный @Test
• При использовании TestNG мы сканируем методы, аннотированные @Test

Примечание . Абстрактные классы не выполняются. Gradle также сканирует дерево наследования в файлы JAR на тестовом пути к классам.

Если вы не хотите использовать обнаружение тестового класса, вы можете отключить его, установив для ScanForTestClasses значение false.

Тестовая группировка

JUnit и TestNG позволяют сложные группы методов тестирования. Для группировки тестовых классов и методов JUnit в JUnit 4.8 вводится понятие категорий. Тестовое задание позволяет указать категории JUnit, которые вы хотите включить и исключить.

Вы можете использовать следующий фрагмент кода в файле build.gradle для группировки методов тестирования.

test {
   useJUnit {
      includeCategories 'org.gradle.junit.CategoryA'
      excludeCategories 'org.gradle.junit.CategoryB'
   }
}

Включить и исключить отдельные тесты

Класс Test имеет метод include и exclude . Эти методы могут использоваться, чтобы указать, какие тесты должны фактически выполняться.

Запускайте только включенные тесты –

test {
   include '**my.package.name/*'
}

Пропустить исключенные тесты –

test {
   exclude '**my.package.name/*'
}

Пример файла build.gradle, как показано ниже, показывает различные параметры конфигурации.

apply plugin: 'java' // adds 'test' task

test {
   // enable TestNG support (default is JUnit)
   useTestNG()

   // set a system property for the test JVM(s)
   systemProperty 'some.prop', 'value'

   // explicitly include or exclude tests
   include 'org/foo/**'
   exclude 'org/boo/**'

   // show standard out and standard error of the test JVM(s) on the console
   testLogging.showStandardStreams = true

   // set heap size for the test JVM(s)
   minHeapSize = "128m"
   maxHeapSize = "512m"

   // set JVM arguments for the test JVM(s)
   jvmArgs '-XX:MaxPermSize=256m'
   
   // listen to events in the test execution lifecycle
   beforeTest { 
      descriptor → logger.lifecycle("Running test: " + descriptor)
   }

   // listen to standard out and standard error of the test JVM(s)
   onOutput { 
      descriptor, event → logger.lifecycle
         ("Test: " + descriptor + " produced standard out/err: " 
         + event.message )
   }
}

Вы можете использовать следующий синтаксис команды для выполнения некоторого тестового задания.

gradle <someTestTask> --debug-jvm

Gradle – Multi-Project Build

Gradle может легко обрабатывать самые маленькие и самые крупные проекты. Небольшие проекты имеют один файл сборки и исходное дерево. Очень легко переварить и понять проект, который был разбит на более мелкие, взаимозависимые модули. Gradle прекрасно поддерживает этот сценарий, который состоит из нескольких проектов.

Структура для мультипроектной сборки

Такие сборки бывают разных форм и размеров, но у них есть некоторые общие характеристики –

• Файл settings.gradle в корневом или главном каталоге проекта.

• Файл build.gradle в корневом или главном каталоге.

• Дочерние каталоги, которые имеют свои собственные файлы сборки * .gradle (в некоторых многопроектных сборках могут отсутствовать сценарии сборки дочерних проектов).

Файл settings.gradle в корневом или главном каталоге проекта.

Файл build.gradle в корневом или главном каталоге.

Дочерние каталоги, которые имеют свои собственные файлы сборки * .gradle (в некоторых многопроектных сборках могут отсутствовать сценарии сборки дочерних проектов).

Для перечисления всех проектов в файле сборки вы можете использовать следующую команду.

C:> gradle -q projects

Выход:

------------------------------------------------------------
Root project
------------------------------------------------------------

Root project 'projectReports'
+--- Project ':api' - The shared API for the application
--- Project ':webapp' - The Web application implementation

To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :api:tasks

В отчете приведено описание каждого проекта, если он указан. Вы можете использовать следующую команду, чтобы указать описание. Вставьте его в файл build.gradle .

description = 'The shared API for the application'

Указание общей конфигурации сборки

В файле build.gradle в root_project общие конфигурации могут применяться ко всем проектам или только к подпроектам.

allprojects {
   group = 'com.example.gradle'
   version = '0.1.0'
}

subprojects {
   apply plugin: 'java'
   apply plugin: 'eclipse'
}

Это указывает общую группу com.example.gradle и версию 0.1.0 для всех проектов. Закрытие подпроектов применяет общие конфигурации для всех подпроектов, но не к корневому проекту, как закрытие всех проектов.

Конкретные конфигурации и зависимости проекта

Основные подпроекты пользовательского интерфейса и утилиты также могут иметь свой собственный файл build.gradle , если у них есть особые потребности, которые еще не применяются общей конфигурацией корневого проекта.

Например, проект пользовательского интерфейса обычно имеет зависимость от основного проекта. Таким образом, проекту пользовательского интерфейса нужен собственный файл build.gradle, чтобы указать эту зависимость.

dependencies {
   compile project(':core')
   compile 'log4j:log4j:1.2.17'
}

Зависимости проекта указываются с помощью метода проекта.

Gradle – Развертывание

Gradle предлагает несколько способов развертывания репозиториев артефактов сборки. При развертывании подписей для ваших артефактов в хранилище Maven вы также захотите подписать опубликованный файл POM.

Использование плагина Maven-publish

плагин maven-publish , предоставляемый Gradle по умолчанию. Используется для публикации скрипта Gradle. Посмотрите на следующий код.

apply plugin: 'java'
apply plugin: 'maven-publish'

publishing {
   publications {
      mavenJava(MavenPublication) {
         from components.java
      }
   }

   repositories {
      maven {
         url "$buildDir/repo"
      }
   }
}

Существует несколько опций публикации, когда применяется плагин Java и maven-publish . Посмотрите на следующий код, он развернет проект в удаленном хранилище.

apply plugin: 'groovy'
apply plugin: 'maven-publish'

group 'workshop'
version = '1.0.0'

publishing {
   publications {
      mavenJava(MavenPublication) { 
         from components.java 
      }
   }
	
   repositories {
      maven {
          default credentials for a nexus repository manager
         credentials {
            username 'admin'
            password 'admin123'
         }
         // url to the releases maven repository
            url "http://localhost:8081/nexus/content/repositories/releases/"
      }
   }
}

Преобразование проекта из Maven в Gradle

Для преобразования файлов Apache Maven pom.xml в файлы сборки Gradle существует специальная команда, если для этой задачи известны все используемые подключаемые модули Maven.

В этом разделе следующая конфигурация pom.xml maven будет преобразована в проект Gradle. Взгляните на это.

<project xmlns = "http://maven.apache.org/POM/4.0.0" 
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
	
   <modelVersion>4.0.0</modelVersion>
   <groupId>com.example.app</groupId>
   <artifactId>example-app</artifactId>
   <packaging>jar</packaging>
   
   <version>1.0.0-SNAPSHOT</version>
	
   <dependencies>
      <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>

         <version>4.11</version>
         <scope>test</scope>
      </dependency>
   </dependencies>
	
</project>

Вы можете использовать следующую команду в командной строке, которая приводит к следующей конфигурации Gradle.

C:> gradle init --type pom

Задача init зависит от задачи оболочки, поэтому создается оболочка Gradle.

Полученный файл build.gradle выглядит примерно так:

apply plugin: 'java'
apply plugin: 'maven'

group = 'com.example.app'
version = '1.0.0-SNAPSHOT'

description = """"""

sourceCompatibility = 1.5
targetCompatibility = 1.5

repositories {
   maven { url "http://repo.maven.apache.org/maven2" }
}

dependencies {
   testCompile group: 'junit', name: 'junit', version:'4.11'
}

Gradle – Eclipse Integration

В этой главе рассказывается об интеграции Eclipse и Gradle. Следуйте приведенным ниже инструкциям, чтобы добавить плагин Gradle для затмения.

Шаг 1 – Откройте Eclipse Marketplace

Прежде всего, откройте затмение, которое установлено в вашей системе. Перейти в помощь -> нажмите на EclipseMarketplace. Посмотрите на следующий скриншот.

Шаг 2 – Установите плагин Buildship

После клика на Eclipse Marketplace вы увидите следующий скриншот. Здесь в левой части панели поиска типа buildship . Buildship – плагин интеграции Gradle. Когда вы найдете сборку на экране, нажмите «Установить» справа. Посмотрите на следующий скриншот.

После этого вы найдете следующий снимок экрана, на котором вам нужно подтвердить установку программного обеспечения, нажав на кнопку подтверждения. Посмотрите на следующий скриншот.

После этого вам нужно нажать «Принять лицензионное соглашение» на следующем экране и нажать «Готово». Посмотрите на следующий скриншот.

Это займет некоторое время для установки. Посмотрите на следующий скриншот.

После этого он попросит перезапустить Eclipse. Там вы выберете Да .

Шаг 3 – Проверка плагина Gradle

При проверке мы создадим новый проект, следуя данной процедуре. В затмении перейдите в файл -> нажмите на новый -> нажмите на другие проекты. Там вы найдете следующий экран. Там выберите Gradle project и нажмите «Далее». Посмотрите на следующий снимок экрана.

После нажатия следующей кнопки вы увидите следующий экран. Там вы укажете путь к домашней директории Gradle локальной файловой системы и нажмите кнопку «Далее». Посмотрите на следующий скриншот.

Взгляните на следующий скриншот, здесь вы дадите название проекту Gradle. В этом уроке мы используем демопроект и нажимаем кнопку « Готово» .

Взгляните на следующий скриншот, нам нужно подтвердить проект. Для этого у нас есть кнопка Готово на следующем экране.

Шаг 4 – Проверка структуры каталогов

После успешной установки плагина Gradle проверьте структуру каталогов демонстрационного проекта на наличие файлов и папок по умолчанию, как показано на следующем снимке экрана.