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

	Maven	Gradle
Конфиг	pom.xml (XML)	build.gradle.kts (Kotlin DSL) или Groovy
Модель	Фиксированные фазы lifecycle	Граф задач (tasks)
Кэш	Локальный .m2	Build cache, configuration cache
Типичный старт	mvn archetype:generate	gradle 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/

Разбор:

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

---

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

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

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы mavenCentral, implementation, testImplementation, set, of, useJUnitPlatform задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

---

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

./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
}

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы id задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

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

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

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы implementation, testImplementation задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

Старт: ./gradlew bootRun.

---

Multi-module

settings.gradle.kts:

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

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы include задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

Каждый подпроект — свой 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")

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы include задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

billing-app/build.gradle.kts:

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

Разбор:

• фрагмент показывает прикладной сценарий по теме раздела: здесь есть входные данные, операции над ними и проверяемый итог.
• ключевые вызовы implementation, project задают основную механику этого примера: обработку, проверку и формирование результата.
• чтение этого блока по шагам дает предсказуемую картину — сначала подготовка данных, затем действие API, затем получение конечного значения.
• после запуска стоит проверить именно эффект этого примера — вывод, значение переменной, статус ответа, состояние БД или результат теста.
• при переносе в production обычно добавляют валидацию входа, явную обработку ошибок и тест на граничные случаи вокруг этого сценария.

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

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

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

---

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

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

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

---

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

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

---

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

• Структура и сборки Java-проектов
• JUnit 5
• Spring Framework

---