Перейти к основному содержимому

Gradle — практический старт

Разработчику Архитектору

Gradle

Gradle — вторая по популярности система сборки на JVM (рядом с Maven). Если в репозитории лежит build.gradle.kts или build.gradle — это Gradle; команды обычно ./gradlew test, а не mvn test.

./gradlew test

Разбор:

  • команды в этом фрагменте выполняются по шагам и составляют практический workflow — запуск, тесты, сборка или проверка окружения.
  • последовательность ./gradlew test покрывает ключевые этапы жизненного цикла проекта в CLI.
  • если одна команда завершается ошибкой, последующие шаги не подтверждают корректность сценария, пока не устранена первопричина.
  • результат смотрят по exit code и по логам команды: успешный статус, ожидаемые артефакты и отсутствие stack trace.
  • такой же набор команд обычно фиксируют в CI, чтобы локальная проверка и pipeline давали одинаковый результат.

Зачем он вам:

  • Spring Boot и Android часто стартуют с Gradle;
  • инкрементальная сборка быстрее на больших проектах;
  • скрипт сборки — код (Kotlin или Groovy).

Эта статья — Kotlin DSL (build.gradle.kts). Groovy-скрипт: Gradle Groovy DSL — первая сборка. Maven целиком: Структура и сборки Java-проектов.

Первый шаг

gradle init → application → Java 17 → Kotlin DSL → ./gradlew run.


Maven и Gradle

MavenGradle
Конфигpom.xml (XML)build.gradle.kts (Kotlin DSL) или Groovy
МодельФиксированные фазы lifecycleГраф задач (tasks)
КэшЛокальный .m2Build cache, configuration cache
Типичный стартmvn archetype:generategradle init

Оба публикуют артефакты в Maven Central с теми же координатами group:artifact:version.


Новый Java-проект

mkdir demo-gradle && cd demo-gradle
gradle init

Разбор:

  • команды в этом фрагменте выполняются по шагам и составляют практический workflow — запуск, тесты, сборка или проверка окружения.
  • последовательность mkdir demo-gradle && cd demo-gradle, gradle init покрывает ключевые этапы жизненного цикла проекта в CLI.
  • если одна команда завершается ошибкой, последующие шаги не подтверждают корректность сценария, пока не устранена первопричина.
  • результат смотрят по exit code и по логам команды: успешный статус, ожидаемые артефакты и отсутствие stack trace.
  • такой же набор команд обычно фиксируют в CI, чтобы локальная проверка и pipeline давали одинаковый результат.

Выберите — application, Java 17+, Kotlin DSL, JUnit 5.

Структура:

demo-gradle/
build.gradle.kts
settings.gradle.kts
gradle/wrapper/ # gradlew — фиксирует версию Gradle
src/main/java/
src/test/java/

build.gradle.kts (минимум)

Код ITЗагрузка примера кода…


Основные команды

./gradlew build # компиляция + тесты + jar
./gradlew test # только тесты
./gradlew bootRun # если подключён Spring Boot plugin
./gradlew dependencies # дерево зависимостей
./gradlew clean

Разбор:

  • команды в этом фрагменте выполняются по шагам и составляют практический workflow — запуск, тесты, сборка или проверка окружения.
  • последовательность ./gradlew build, ./gradlew test, ./gradlew bootRun, ./gradlew dependencies покрывает ключевые этапы жизненного цикла проекта в CLI.
  • если одна команда завершается ошибкой, последующие шаги не подтверждают корректность сценария, пока не устранена первопричина.
  • результат смотрят по exit code и по логам команды: успешный статус, ожидаемые артефакты и отсутствие stack trace.
  • такой же набор команд обычно фиксируют в CI, чтобы локальная проверка и pipeline давали одинаковый результат.

На Windows: gradlew.bat вместо ./gradlew.


Spring Boot с Gradle

plugins block:

plugins {
id("org.springframework.boot") version "3.2.5"
id("io.spring.dependency-management") version "1.1.4"
java
}

Зависимости без версий (управляются BOM):

dependencies {
implementation("org.springframework.boot:spring-boot-starter-web")
testImplementation("org.springframework.boot:spring-boot-starter-test")
}

Старт: ./gradlew bootRun.


Multi-module

settings.gradle.kts:

rootProject.name = "my-platform"
include("api", "core", "infra")

Каждый подпроект — свой build.gradle.kts. Общие версии выносят в gradle/libs.versions.toml (Version Catalog).


Как читать build.gradle.kts в чужом проекте

Когда вы открываете незнакомый репозиторий на Gradle, проходите файл сборки в таком порядке:

  1. plugins — какие возможности подключены (Java, Spring Boot, публикация, линтеры).
  2. java.toolchain — на какой версии JDK проект собирается реально.
  3. repositories — откуда подтягиваются зависимости.
  4. dependencies — основной стек приложения и тестов.
  5. tasks — особые правила сборки, тестов и упаковки.

Такой порядок быстро отвечает на практические вопросы — "почему локально не собирается", "какой JDK нужен в CI", "чем проект запускается".


Практический сценарий — библиотека плюс приложение

Частый кейс в командах: один модуль с бизнес-логикой и второй модуль как исполняемое приложение.

settings.gradle.kts:

rootProject.name = "billing-platform"
include("billing-core", "billing-app")

billing-app/build.gradle.kts:

dependencies {
implementation(project(":billing-core"))
implementation("org.springframework.boot:spring-boot-starter-web")
}

Что это дает в реальной разработке:

  • billing-core можно тестировать отдельно и переиспользовать;
  • в billing-app остается только слой API и конфигурация;
  • сборка на CI прозрачнее: видно, какой модуль упал и почему.

О модульности и архитектуре полезно читать вместе с ООП в Java и Spring Framework.


Типичные проблемы и быстрые решения

СимптомЧастая причинаЧто проверить
Unsupported class file major versionJDK новее или старее, чем ожидает сборкаjava -version и toolchain
Зависимость "не находится"Нет mavenCentral() или закрыт репозиторийблок repositories
Тесты проходят локально и падают в CIРазные версии Java/Gradlewrapper gradlew и pipeline
Команда bootRun не существуетНет Spring Boot pluginблок plugins

Для диагностики среды смотрите также конфигурации JVM и ввод-вывод в Java, если проблема связана с путями или кодировкой.


Мини-чек-лист перед коммитом

  • Сборка проходит командой ./gradlew clean build.
  • Все зависимости описаны в build.gradle.kts, без ручных JAR в проекте.
  • Версия Java фиксируется через toolchain, а не "как получится у разработчика".
  • Добавлены базовые тесты на новый функционал (JUnit 5).

Связанные материалы