При использовании стандартного плагина Java Gradle предоставляет ряд задач (tasks) по умолчанию:
clean: удаляет каталог build/ (результаты предыдущих сборок).
compileJava: компиляция кода (также есть отдельные tasks для компиляции тестов – compileTestJava).
test: запускает юнит-тесты (с использованием JUnit или другого фреймворка, если подключен).
jar: упаковывает скомпилированный код и ресурсы в JAR-файл (находится в build/libs).
assemble: собирает артефакты без запуска тестов. Обычно включает в себя jar (и, например, war если веб-плагин) – используется, когда нужно только собрать.
check: выполняет все проверки качества, включая запуск тестов. Часто check зависит от test и других проверок (например, линтеров).
build: полная сборка проекта. По умолчанию включает assemble и check (то есть и сборку, и тестирование). Команда gradle build создает артефакт и прогоняет тесты.
run: если подключен плагин Application и задан mainClass, позволяет запустить приложение (gradle run).
tasks: выводит список всех доступных задач в проекте (полезно для ознакомления).
Другие задачи: Gradle и плагины могут добавлять много задач (например, javadoc для генерации документации, testCoverage при подключении JaCoCo, и т.д.). Их список зависит от активных плагинов.
Пояснение: Gradle-терминология: задача (task) – эквивалент шага сборки. Плагин java добавляет десятки задач, но обычно интерес представляют вышеперечисленные основные:
clean: аналог Maven clean. Удаляет директорию build в текущем проекте (и подмодулях, если запускается в корне). Обычно запускается отдельно: gradle clean или комбинируется (gradle clean build). Gradle не делает автоматический clean перед сборкой, это остается на усмотрение разработчика или скриптов CI.
compileJava: компиляция основного кода. Есть и compileKotlin, если Kotlin-плагин, compileGroovy – зависит от языков. Эти задачи вызываются автоматически, если нужны: например, build включает compileJava в свою цепочку.
processResources: (тоже важная) – копирование ресурсов из src/main/resources в build/resources/main. Выполняется в связке с compileJava.
classes: объединяет compileJava + processResources (готовит .class файлы и ресурсы).
jar: берет результаты classes и упаковывает в JAR. Можно настроить, добавить в JAR дополнительные файлы, изменить манифест и т.п.
assemble: мета-задача, которая зависит от всех задач, производящих конечные артефакты (в Java-проекте это jar; в War-проекте – war; в многомодульном – все артефакты модулей). Запуск gradle assemble приведет к компиляции и упаковке, но не запустит тесты.
test: Gradle генерирует эту задачу (через плагин Java), используя JUnit или TestNG. Она компилирует тестовый код (compileTestJava), копирует тестовые ресурсы (processTestResources), затем запускает сами тесты (task test делает все эти подзадачи). Результаты тестов сохраняются в build/test-results (и отчет в build/reports/tests/test/index.html).
check: тоже сборная задача. По умолчанию check зависит от test. Если вы добавляете другие проверяющие плагины (например, checkstyle, pmd, spotbugs), их задачи тоже привязываются к check. Таким образом, gradle check обычно запускают на CI, чтобы выполнить все виды проверок кода.
build: финальная сборка. По умолчанию Gradle делает build зависимым от assemble и check. То есть gradle build = скомпилировать и упаковать + выполнить тесты (и другие проверки). Это аналог mvn package + тесты (Maven, правда, включает тесты всегда до packaging).
run: если применен плагин Application (часто в standalone приложениях), то появляется задача run, которая запускает указанный mainClass. Удобно во время разработки: gradle run соберет, а затем запустит программу.
tasks: вспомогательная, выводит разбитый по группам список задач, доступных в текущем проекте. Помогает узнать, что можно запустить. Аналог в Maven – mvn help:describe для конкретного плагина или чтение документации; Gradle прямо в CLI показывает.
Кроме того, Gradle генерирует и другие задачи:
buildNeeded, buildDependents: полезно в многомодульных сборках (построить только необходимые модули).
help: вывод справки.
dependencies: покажет дерево зависимостей конфигураций.
components, artifacts: для публикации, нечасто используются напрямую.
wrapper: интересная задача – gradle wrapper генерирует скрипты Gradle Wrapper (gradlew), если они еще не в проекте, или обновляет их под текущую версию Gradle.
Создание своих задач: Gradle позволяет добавлять кастомные задачи очень легко. Например, вы можете в build.gradle прописать:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Теперь командой gradle hello выведется это сообщение. Эта простейшая задача. Вы можете настроить зависимости между своими задачами: task deploy(dependsOn: ['build', 'dockerBuild']) { ... } – скажем, для деплоя требуем сначала собрать проект и Docker-образ. Gradle выполнит build и dockerBuild (если они определены) прежде чем зайти в тело deploy. Внутри задачи (doLast) можно выполнять любой код: вызывать shell-команды, API, генерировать файлы – все что угодно, используя мощь JVM. В Maven для таких вещей приходилось искать или писать плагин (Maven не позволяет встроить произвольный код Java прямо в POM, только через плагины).
Современные практики:
В Android проектах часто кроме стандартных задач есть специфичные, типа assembleDebug, assembleRelease, installDebug (они создаются плагинами Android).
В backend Gradle-проектах многие подключают плагин ShadowJar для толстых JAR (задача shadowJar), плагин Docker для сборки контейнера (задача docker), плагин jib (задача jib для пуша образа), плагин SpotBugs/Checkstyle (задачи spotbugsMain, checkstyleMain и т.п., которые привязаны к check).
Есть даже плагин gradle-maven-publish-plugin, который добавляет задачи публикации артефактов в Maven-репозитории (publish, publishToMavenLocal).
Для повышения производительности сборки при больших кодовых базах на CI может использоваться gradle build --parallel --scan (parallel — параллельная сборка, scan — генерация build scan отчета).
Также, Gradle Wrapper запускают с определенными флагами: например, ./gradlew build -Dorg.gradle.daemon=false чтобы явно контролировать демон Gradle, или --build-cache чтобы включить кэш.
Но в сути: освоив стандартные задачи (clean, build, test, etc.), вы уже можете работать с Gradle. Остальное – по мере необходимости добавляется.
Gradle: Основные задачи сборки
При использовании стандартного плагина Java Gradle предоставляет ряд задач (tasks) по умолчанию:
clean: удаляет каталог build/ (результаты предыдущих сборок).
compileJava: компиляция кода (также есть отдельные tasks для компиляции тестов – compileTestJava).
test: запускает юнит-тесты (с использованием JUnit или другого фреймворка, если подключен).
jar: упаковывает скомпилированный код и ресурсы в JAR-файл (находится в build/libs).
assemble: собирает артефакты без запуска тестов. Обычно включает в себя jar (и, например, war если веб-плагин) – используется, когда нужно только собрать.
check: выполняет все проверки качества, включая запуск тестов. Часто check зависит от test и других проверок (например, линтеров).
build: полная сборка проекта. По умолчанию включает assemble и check (то есть и сборку, и тестирование). Команда gradle build создает артефакт и прогоняет тесты.
run: если подключен плагин Application и задан mainClass, позволяет запустить приложение (gradle run).
tasks: выводит список всех доступных задач в проекте (полезно для ознакомления).
Другие задачи: Gradle и плагины могут добавлять много задач (например, javadoc для генерации документации, testCoverage при подключении JaCoCo, и т.д.). Их список зависит от активных плагинов.
Пояснение: Gradle-терминология: задача (task) – эквивалент шага сборки. Плагин java добавляет десятки задач, но обычно интерес представляют вышеперечисленные основные:
clean: аналог Maven clean. Удаляет директорию build в текущем проекте (и подмодулях, если запускается в корне). Обычно запускается отдельно: gradle clean или комбинируется (gradle clean build). Gradle не делает автоматический clean перед сборкой, это остается на усмотрение разработчика или скриптов CI.
compileJava: компиляция основного кода. Есть и compileKotlin, если Kotlin-плагин, compileGroovy – зависит от языков. Эти задачи вызываются автоматически, если нужны: например, build включает compileJava в свою цепочку.
processResources: (тоже важная) – копирование ресурсов из src/main/resources в build/resources/main. Выполняется в связке с compileJava.
classes: объединяет compileJava + processResources (готовит .class файлы и ресурсы).
jar: берет результаты classes и упаковывает в JAR. Можно настроить, добавить в JAR дополнительные файлы, изменить манифест и т.п.
assemble: мета-задача, которая зависит от всех задач, производящих конечные артефакты (в Java-проекте это jar; в War-проекте – war; в многомодульном – все артефакты модулей). Запуск gradle assemble приведет к компиляции и упаковке, но не запустит тесты.
test: Gradle генерирует эту задачу (через плагин Java), используя JUnit или TestNG. Она компилирует тестовый код (compileTestJava), копирует тестовые ресурсы (processTestResources), затем запускает сами тесты (task test делает все эти подзадачи). Результаты тестов сохраняются в build/test-results (и отчет в build/reports/tests/test/index.html).
check: тоже сборная задача. По умолчанию check зависит от test. Если вы добавляете другие проверяющие плагины (например, checkstyle, pmd, spotbugs), их задачи тоже привязываются к check. Таким образом, gradle check обычно запускают на CI, чтобы выполнить все виды проверок кода.
build: финальная сборка. По умолчанию Gradle делает build зависимым от assemble и check. То есть gradle build = скомпилировать и упаковать + выполнить тесты (и другие проверки). Это аналог mvn package + тесты (Maven, правда, включает тесты всегда до packaging).
run: если применен плагин Application (часто в standalone приложениях), то появляется задача run, которая запускает указанный mainClass. Удобно во время разработки: gradle run соберет, а затем запустит программу.
tasks: вспомогательная, выводит разбитый по группам список задач, доступных в текущем проекте. Помогает узнать, что можно запустить. Аналог в Maven – mvn help:describe для конкретного плагина или чтение документации; Gradle прямо в CLI показывает.
Кроме того, Gradle генерирует и другие задачи:
buildNeeded, buildDependents: полезно в многомодульных сборках (построить только необходимые модули).
help: вывод справки.
dependencies: покажет дерево зависимостей конфигураций.
components, artifacts: для публикации, нечасто используются напрямую.
wrapper: интересная задача – gradle wrapper генерирует скрипты Gradle Wrapper (gradlew), если они еще не в проекте, или обновляет их под текущую версию Gradle.
Создание своих задач: Gradle позволяет добавлять кастомные задачи очень легко. Например, вы можете в build.gradle прописать:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Теперь командой gradle hello выведется это сообщение. Эта простейшая задача. Вы можете настроить зависимости между своими задачами: task deploy(dependsOn: ['build', 'dockerBuild']) { ... } – скажем, для деплоя требуем сначала собрать проект и Docker-образ. Gradle выполнит build и dockerBuild (если они определены) прежде чем зайти в тело deploy. Внутри задачи (doLast) можно выполнять любой код: вызывать shell-команды, API, генерировать файлы – все что угодно, используя мощь JVM. В Maven для таких вещей приходилось искать или писать плагин (Maven не позволяет встроить произвольный код Java прямо в POM, только через плагины).
Современные практики:
В Android проектах часто кроме стандартных задач есть специфичные, типа assembleDebug, assembleRelease, installDebug (они создаются плагинами Android).
В backend Gradle-проектах многие подключают плагин ShadowJar для толстых JAR (задача shadowJar), плагин Docker для сборки контейнера (задача docker), плагин jib (задача jib для пуша образа), плагин SpotBugs/Checkstyle (задачи spotbugsMain, checkstyleMain и т.п., которые привязаны к check).
Есть даже плагин gradle-maven-publish-plugin, который добавляет задачи публикации артефактов в Maven-репозитории (publish, publishToMavenLocal).
Для повышения производительности сборки при больших кодовых базах на CI может использоваться gradle build --parallel --scan (parallel — параллельная сборка, scan — генерация build scan отчета).
Также, Gradle Wrapper запускают с определенными флагами: например, ./gradlew build -Dorg.gradle.daemon=false чтобы явно контролировать демон Gradle, или --build-cache чтобы включить кэш.
Но в сути: освоив стандартные задачи (clean, build, test, etc.), вы уже можете работать с Gradle. Остальное – по мере необходимости добавляется.
clean: удаляет каталог build/ (результаты предыдущих сборок).
compileJava: компиляция кода (также есть отдельные tasks для компиляции тестов – compileTestJava).
test: запускает юнит-тесты (с использованием JUnit или другого фреймворка, если подключен).
jar: упаковывает скомпилированный код и ресурсы в JAR-файл (находится в build/libs).
assemble: собирает артефакты без запуска тестов. Обычно включает в себя jar (и, например, war если веб-плагин) – используется, когда нужно только собрать.
check: выполняет все проверки качества, включая запуск тестов. Часто check зависит от test и других проверок (например, линтеров).
build: полная сборка проекта. По умолчанию включает assemble и check (то есть и сборку, и тестирование). Команда gradle build создает артефакт и прогоняет тесты.
run: если подключен плагин Application и задан mainClass, позволяет запустить приложение (gradle run).
tasks: выводит список всех доступных задач в проекте (полезно для ознакомления).
Другие задачи: Gradle и плагины могут добавлять много задач (например, javadoc для генерации документации, testCoverage при подключении JaCoCo, и т.д.). Их список зависит от активных плагинов.
Пояснение: Gradle-терминология: задача (task) – эквивалент шага сборки. Плагин java добавляет десятки задач, но обычно интерес представляют вышеперечисленные основные:
clean: аналог Maven clean. Удаляет директорию build в текущем проекте (и подмодулях, если запускается в корне). Обычно запускается отдельно: gradle clean или комбинируется (gradle clean build). Gradle не делает автоматический clean перед сборкой, это остается на усмотрение разработчика или скриптов CI.
compileJava: компиляция основного кода. Есть и compileKotlin, если Kotlin-плагин, compileGroovy – зависит от языков. Эти задачи вызываются автоматически, если нужны: например, build включает compileJava в свою цепочку.
processResources: (тоже важная) – копирование ресурсов из src/main/resources в build/resources/main. Выполняется в связке с compileJava.
classes: объединяет compileJava + processResources (готовит .class файлы и ресурсы).
jar: берет результаты classes и упаковывает в JAR. Можно настроить, добавить в JAR дополнительные файлы, изменить манифест и т.п.
assemble: мета-задача, которая зависит от всех задач, производящих конечные артефакты (в Java-проекте это jar; в War-проекте – war; в многомодульном – все артефакты модулей). Запуск gradle assemble приведет к компиляции и упаковке, но не запустит тесты.
test: Gradle генерирует эту задачу (через плагин Java), используя JUnit или TestNG. Она компилирует тестовый код (compileTestJava), копирует тестовые ресурсы (processTestResources), затем запускает сами тесты (task test делает все эти подзадачи). Результаты тестов сохраняются в build/test-results (и отчет в build/reports/tests/test/index.html).
check: тоже сборная задача. По умолчанию check зависит от test. Если вы добавляете другие проверяющие плагины (например, checkstyle, pmd, spotbugs), их задачи тоже привязываются к check. Таким образом, gradle check обычно запускают на CI, чтобы выполнить все виды проверок кода.
build: финальная сборка. По умолчанию Gradle делает build зависимым от assemble и check. То есть gradle build = скомпилировать и упаковать + выполнить тесты (и другие проверки). Это аналог mvn package + тесты (Maven, правда, включает тесты всегда до packaging).
run: если применен плагин Application (часто в standalone приложениях), то появляется задача run, которая запускает указанный mainClass. Удобно во время разработки: gradle run соберет, а затем запустит программу.
tasks: вспомогательная, выводит разбитый по группам список задач, доступных в текущем проекте. Помогает узнать, что можно запустить. Аналог в Maven – mvn help:describe для конкретного плагина или чтение документации; Gradle прямо в CLI показывает.
Кроме того, Gradle генерирует и другие задачи:
buildNeeded, buildDependents: полезно в многомодульных сборках (построить только необходимые модули).
help: вывод справки.
dependencies: покажет дерево зависимостей конфигураций.
components, artifacts: для публикации, нечасто используются напрямую.
wrapper: интересная задача – gradle wrapper генерирует скрипты Gradle Wrapper (gradlew), если они еще не в проекте, или обновляет их под текущую версию Gradle.
Создание своих задач: Gradle позволяет добавлять кастомные задачи очень легко. Например, вы можете в build.gradle прописать:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Теперь командой gradle hello выведется это сообщение. Эта простейшая задача. Вы можете настроить зависимости между своими задачами: task deploy(dependsOn: ['build', 'dockerBuild']) { ... } – скажем, для деплоя требуем сначала собрать проект и Docker-образ. Gradle выполнит build и dockerBuild (если они определены) прежде чем зайти в тело deploy. Внутри задачи (doLast) можно выполнять любой код: вызывать shell-команды, API, генерировать файлы – все что угодно, используя мощь JVM. В Maven для таких вещей приходилось искать или писать плагин (Maven не позволяет встроить произвольный код Java прямо в POM, только через плагины).
Современные практики:
В Android проектах часто кроме стандартных задач есть специфичные, типа assembleDebug, assembleRelease, installDebug (они создаются плагинами Android).
В backend Gradle-проектах многие подключают плагин ShadowJar для толстых JAR (задача shadowJar), плагин Docker для сборки контейнера (задача docker), плагин jib (задача jib для пуша образа), плагин SpotBugs/Checkstyle (задачи spotbugsMain, checkstyleMain и т.п., которые привязаны к check).
Есть даже плагин gradle-maven-publish-plugin, который добавляет задачи публикации артефактов в Maven-репозитории (publish, publishToMavenLocal).
Для повышения производительности сборки при больших кодовых базах на CI может использоваться gradle build --parallel --scan (parallel — параллельная сборка, scan — генерация build scan отчета).
Также, Gradle Wrapper запускают с определенными флагами: например, ./gradlew build -Dorg.gradle.daemon=false чтобы явно контролировать демон Gradle, или --build-cache чтобы включить кэш.
Но в сути: освоив стандартные задачи (clean, build, test, etc.), вы уже можете работать с Gradle. Остальное – по мере необходимости добавляется.
Автор: к.п.н., Румянцев Сергей Александрович, доцент Финансового университета при Правительстве РФ; доцент ОЧУВО Международного инновационного университета; Консалтинг, управление разработкой ПО; системный и бизнес анализ; менеджмент; аналитиз данных; управление ИТ. Телефон для связи +79269444818 (мессенджеры)
Короткая ссылка:
При использовании стандартного плагина Java Gradle предоставляет ряд задач (tasks) по умолчанию:
clean: удаляет каталог build/ (результаты предыдущих сборок).
compileJava: компиляция кода (также есть отдельные tasks для компиляции тестов – compileTestJava).
test: запускает юнит-тесты (с использованием JUnit или другого фреймворка, если подключен).
jar: упаковывает скомпилированный код и ресурсы в JAR-файл (находится в build/libs).
assemble: собирает артефакты без запуска тестов. Обычно включает в себя jar (и, например, war если веб-плагин) – используется, когда нужно только собрать.
check: выполняет все проверки качества, включая запуск тестов. Часто check зависит от test и других проверок (например, линтеров).
build: полная сборка проекта. По умолчанию включает assemble и check (то есть и сборку, и тестирование). Команда gradle build создает артефакт и прогоняет тесты.
run: если подключен плагин Application и задан mainClass, позволяет запустить приложение (gradle run).
tasks: выводит список всех доступных задач в проекте (полезно для ознакомления).
Другие задачи: Gradle и плагины могут добавлять много задач (например, javadoc для генерации документации, testCoverage при подключении JaCoCo, и т.д.). Их список зависит от активных плагинов.
Пояснение: Gradle-терминология: задача (task) – эквивалент шага сборки. Плагин java добавляет десятки задач, но обычно интерес представляют вышеперечисленные основные:
clean: аналог Maven clean. Удаляет директорию build в текущем проекте (и подмодулях, если запускается в корне). Обычно запускается отдельно: gradle clean или комбинируется (gradle clean build). Gradle не делает автоматический clean перед сборкой, это остается на усмотрение разработчика или скриптов CI.
compileJava: компиляция основного кода. Есть и compileKotlin, если Kotlin-плагин, compileGroovy – зависит от языков. Эти задачи вызываются автоматически, если нужны: например, build включает compileJava в свою цепочку.
processResources: (тоже важная) – копирование ресурсов из src/main/resources в build/resources/main. Выполняется в связке с compileJava.
classes: объединяет compileJava + processResources (готовит .class файлы и ресурсы).
jar: берет результаты classes и упаковывает в JAR. Можно настроить, добавить в JAR дополнительные файлы, изменить манифест и т.п.
assemble: мета-задача, которая зависит от всех задач, производящих конечные артефакты (в Java-проекте это jar; в War-проекте – war; в многомодульном – все артефакты модулей). Запуск gradle assemble приведет к компиляции и упаковке, но не запустит тесты.
test: Gradle генерирует эту задачу (через плагин Java), используя JUnit или TestNG. Она компилирует тестовый код (compileTestJava), копирует тестовые ресурсы (processTestResources), затем запускает сами тесты (task test делает все эти подзадачи). Результаты тестов сохраняются в build/test-results (и отчет в build/reports/tests/test/index.html).
check: тоже сборная задача. По умолчанию check зависит от test. Если вы добавляете другие проверяющие плагины (например, checkstyle, pmd, spotbugs), их задачи тоже привязываются к check. Таким образом, gradle check обычно запускают на CI, чтобы выполнить все виды проверок кода.
build: финальная сборка. По умолчанию Gradle делает build зависимым от assemble и check. То есть gradle build = скомпилировать и упаковать + выполнить тесты (и другие проверки). Это аналог mvn package + тесты (Maven, правда, включает тесты всегда до packaging).
run: если применен плагин Application (часто в standalone приложениях), то появляется задача run, которая запускает указанный mainClass. Удобно во время разработки: gradle run соберет, а затем запустит программу.
tasks: вспомогательная, выводит разбитый по группам список задач, доступных в текущем проекте. Помогает узнать, что можно запустить. Аналог в Maven – mvn help:describe для конкретного плагина или чтение документации; Gradle прямо в CLI показывает.
Кроме того, Gradle генерирует и другие задачи:
buildNeeded, buildDependents: полезно в многомодульных сборках (построить только необходимые модули).
help: вывод справки.
dependencies: покажет дерево зависимостей конфигураций.
components, artifacts: для публикации, нечасто используются напрямую.
wrapper: интересная задача – gradle wrapper генерирует скрипты Gradle Wrapper (gradlew), если они еще не в проекте, или обновляет их под текущую версию Gradle.
Создание своих задач: Gradle позволяет добавлять кастомные задачи очень легко. Например, вы можете в build.gradle прописать:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Теперь командой gradle hello выведется это сообщение. Эта простейшая задача. Вы можете настроить зависимости между своими задачами: task deploy(dependsOn: ['build', 'dockerBuild']) { ... } – скажем, для деплоя требуем сначала собрать проект и Docker-образ. Gradle выполнит build и dockerBuild (если они определены) прежде чем зайти в тело deploy. Внутри задачи (doLast) можно выполнять любой код: вызывать shell-команды, API, генерировать файлы – все что угодно, используя мощь JVM. В Maven для таких вещей приходилось искать или писать плагин (Maven не позволяет встроить произвольный код Java прямо в POM, только через плагины).
Современные практики:
В Android проектах часто кроме стандартных задач есть специфичные, типа assembleDebug, assembleRelease, installDebug (они создаются плагинами Android).
В backend Gradle-проектах многие подключают плагин ShadowJar для толстых JAR (задача shadowJar), плагин Docker для сборки контейнера (задача docker), плагин jib (задача jib для пуша образа), плагин SpotBugs/Checkstyle (задачи spotbugsMain, checkstyleMain и т.п., которые привязаны к check).
Есть даже плагин gradle-maven-publish-plugin, который добавляет задачи публикации артефактов в Maven-репозитории (publish, publishToMavenLocal).
Для повышения производительности сборки при больших кодовых базах на CI может использоваться gradle build --parallel --scan (parallel — параллельная сборка, scan — генерация build scan отчета).
Также, Gradle Wrapper запускают с определенными флагами: например, ./gradlew build -Dorg.gradle.daemon=false чтобы явно контролировать демон Gradle, или --build-cache чтобы включить кэш.
Но в сути: освоив стандартные задачи (clean, build, test, etc.), вы уже можете работать с Gradle. Остальное – по мере необходимости добавляется.
https://webprogr.ru/~ebb5R
clean: удаляет каталог build/ (результаты предыдущих сборок).
compileJava: компиляция кода (также есть отдельные tasks для компиляции тестов – compileTestJava).
test: запускает юнит-тесты (с использованием JUnit или другого фреймворка, если подключен).
jar: упаковывает скомпилированный код и ресурсы в JAR-файл (находится в build/libs).
assemble: собирает артефакты без запуска тестов. Обычно включает в себя jar (и, например, war если веб-плагин) – используется, когда нужно только собрать.
check: выполняет все проверки качества, включая запуск тестов. Часто check зависит от test и других проверок (например, линтеров).
build: полная сборка проекта. По умолчанию включает assemble и check (то есть и сборку, и тестирование). Команда gradle build создает артефакт и прогоняет тесты.
run: если подключен плагин Application и задан mainClass, позволяет запустить приложение (gradle run).
tasks: выводит список всех доступных задач в проекте (полезно для ознакомления).
Другие задачи: Gradle и плагины могут добавлять много задач (например, javadoc для генерации документации, testCoverage при подключении JaCoCo, и т.д.). Их список зависит от активных плагинов.
Пояснение: Gradle-терминология: задача (task) – эквивалент шага сборки. Плагин java добавляет десятки задач, но обычно интерес представляют вышеперечисленные основные:
clean: аналог Maven clean. Удаляет директорию build в текущем проекте (и подмодулях, если запускается в корне). Обычно запускается отдельно: gradle clean или комбинируется (gradle clean build). Gradle не делает автоматический clean перед сборкой, это остается на усмотрение разработчика или скриптов CI.
compileJava: компиляция основного кода. Есть и compileKotlin, если Kotlin-плагин, compileGroovy – зависит от языков. Эти задачи вызываются автоматически, если нужны: например, build включает compileJava в свою цепочку.
processResources: (тоже важная) – копирование ресурсов из src/main/resources в build/resources/main. Выполняется в связке с compileJava.
classes: объединяет compileJava + processResources (готовит .class файлы и ресурсы).
jar: берет результаты classes и упаковывает в JAR. Можно настроить, добавить в JAR дополнительные файлы, изменить манифест и т.п.
assemble: мета-задача, которая зависит от всех задач, производящих конечные артефакты (в Java-проекте это jar; в War-проекте – war; в многомодульном – все артефакты модулей). Запуск gradle assemble приведет к компиляции и упаковке, но не запустит тесты.
test: Gradle генерирует эту задачу (через плагин Java), используя JUnit или TestNG. Она компилирует тестовый код (compileTestJava), копирует тестовые ресурсы (processTestResources), затем запускает сами тесты (task test делает все эти подзадачи). Результаты тестов сохраняются в build/test-results (и отчет в build/reports/tests/test/index.html).
check: тоже сборная задача. По умолчанию check зависит от test. Если вы добавляете другие проверяющие плагины (например, checkstyle, pmd, spotbugs), их задачи тоже привязываются к check. Таким образом, gradle check обычно запускают на CI, чтобы выполнить все виды проверок кода.
build: финальная сборка. По умолчанию Gradle делает build зависимым от assemble и check. То есть gradle build = скомпилировать и упаковать + выполнить тесты (и другие проверки). Это аналог mvn package + тесты (Maven, правда, включает тесты всегда до packaging).
run: если применен плагин Application (часто в standalone приложениях), то появляется задача run, которая запускает указанный mainClass. Удобно во время разработки: gradle run соберет, а затем запустит программу.
tasks: вспомогательная, выводит разбитый по группам список задач, доступных в текущем проекте. Помогает узнать, что можно запустить. Аналог в Maven – mvn help:describe для конкретного плагина или чтение документации; Gradle прямо в CLI показывает.
Кроме того, Gradle генерирует и другие задачи:
buildNeeded, buildDependents: полезно в многомодульных сборках (построить только необходимые модули).
help: вывод справки.
dependencies: покажет дерево зависимостей конфигураций.
components, artifacts: для публикации, нечасто используются напрямую.
wrapper: интересная задача – gradle wrapper генерирует скрипты Gradle Wrapper (gradlew), если они еще не в проекте, или обновляет их под текущую версию Gradle.
Создание своих задач: Gradle позволяет добавлять кастомные задачи очень легко. Например, вы можете в build.gradle прописать:
task hello {
doLast {
println 'Hello, Gradle!'
}
}
Теперь командой gradle hello выведется это сообщение. Эта простейшая задача. Вы можете настроить зависимости между своими задачами: task deploy(dependsOn: ['build', 'dockerBuild']) { ... } – скажем, для деплоя требуем сначала собрать проект и Docker-образ. Gradle выполнит build и dockerBuild (если они определены) прежде чем зайти в тело deploy. Внутри задачи (doLast) можно выполнять любой код: вызывать shell-команды, API, генерировать файлы – все что угодно, используя мощь JVM. В Maven для таких вещей приходилось искать или писать плагин (Maven не позволяет встроить произвольный код Java прямо в POM, только через плагины).
Современные практики:
В Android проектах часто кроме стандартных задач есть специфичные, типа assembleDebug, assembleRelease, installDebug (они создаются плагинами Android).
В backend Gradle-проектах многие подключают плагин ShadowJar для толстых JAR (задача shadowJar), плагин Docker для сборки контейнера (задача docker), плагин jib (задача jib для пуша образа), плагин SpotBugs/Checkstyle (задачи spotbugsMain, checkstyleMain и т.п., которые привязаны к check).
Есть даже плагин gradle-maven-publish-plugin, который добавляет задачи публикации артефактов в Maven-репозитории (publish, publishToMavenLocal).
Для повышения производительности сборки при больших кодовых базах на CI может использоваться gradle build --parallel --scan (parallel — параллельная сборка, scan — генерация build scan отчета).
Также, Gradle Wrapper запускают с определенными флагами: например, ./gradlew build -Dorg.gradle.daemon=false чтобы явно контролировать демон Gradle, или --build-cache чтобы включить кэш.
Но в сути: освоив стандартные задачи (clean, build, test, etc.), вы уже можете работать с Gradle. Остальное – по мере необходимости добавляется.
Короткая ссылка на новость:https://webprogr.ru/~ebb5R
Последние новости