Плагины и расширение функциональности в Gradle

Плагины в Gradle — это основной механизм расширения функциональности, позволяющий добавлять задачи, конфигурации и зависимости для автоматизации сборки. Они обеспечивают модульность и гибкость, позволяя адаптировать Gradle под конкретные проекты. Эта статья подробно описывает типы плагинов, встроенные и сторонние плагины, создание собственных плагинов, публикацию на Gradle Plugin Portal, стратегии разрешения плагинов и управление через pluginManagement. Особое внимание уделяется внутренним механизмам, управлению памятью и нюансам.


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

Gradle поддерживает два основных типа плагинов: Script Plugins и Binary Plugins.

Script Plugin (apply from)
Описание: Скриптовые плагины — это файлы Gradle (обычно .gradle или .gradle.kts), которые содержат логику сборки и подключаются к build.gradle через apply from.

Пример (Groovy DSL):

apply from: 'other.gradle'

Содержимое other.gradle:

task customTask {
    doLast {
        println 'Custom task from script plugin'
    }
}

Kotlin DSL:

apply(from = "other.gradle.kts")

Содержимое other.gradle.kts:

tasks.register("customTask") {
    doLast {
        println("Custom task from script plugin")
    }
}

Использование: Для небольших проектов или повторно используемых фрагментов кода в рамках одного проекта.

В памяти: Скриптовые плагины парсятся как обычные Gradle-скрипты, добавляя задачи и конфигурации в модель проекта. Это увеличивает потребление памяти, аналогично основному build.gradle, но overhead минимален (10-50 МБ).

Binary Plugin (apply plugin:)
Описание: Бинарные плагины — это скомпилированные Java/Groovy/Kotlin-классы, распространяемые как JAR-файлы. Они подключаются через apply plugin или блок plugins.

Пример (Groovy DSL):

apply plugin: 'java'

В памяти: Бинарные плагины загружаются как Java-классы в JVM, включая их зависимости. Это увеличивает потребление памяти пропорционально сложности плагина (50-200 МБ для крупных плагинов, таких как android).

plugins {} vs apply plugin:

plugins {}:
Современный способ подключения плагинов, введенный в Gradle 2.1.
Использует декларативный синтаксис и разрешает плагины из Gradle Plugin Portal или репозиториев.

Пример:

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.18'
}

Kotlin DSL:

plugins {
    java
    id("org.springframework.boot") version "2.7.18"
}

Преимущества: Автоматическое разрешение версий, поддержка Gradle Plugin Portal, меньшая вероятность ошибок.


apply plugin:
Традиционный способ, используемый в старых версиях Gradle.

Требует явного указания зависимости в buildscript:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.7.18'
    }
}
apply plugin: 'org.springframework.boot'

Недостатки: Более многословный, требует ручного управления зависимостями.

В памяти: plugins {} использует внутренний механизм разрешения Gradle, минимизируя overhead по сравнению с buildscript, который загружает дополнительные зависимости в classpath.

Рекомендация: Используйте plugins {} для современных проектов, так как он проще и поддерживает автоматическое разрешение.


#Java #middle #Gradle #Task #Plugin

Built-in плагины

Gradle поставляется с набором встроенных плагинов, которые покрывают стандартные сценарии сборки.

java:
Добавляет задачи для компиляции, тестирования и упаковки Java-проектов (например, compileJava, test, jar).

Пример:

plugins {
    id 'java'
}

В памяти: Загружает задачи и конфигурации (implementation, testImplementation), увеличивая модель проекта (50-100 МБ).

application:
Добавляет задачи для запуска Java-приложений (run, installDist).

Пример:

plugins {
    id 'application'
}
application {
    mainClass = 'com.example.Main'
}

В памяти: Добавляет задачи и classpath, минимально увеличивая overhead.

base:
Базовый плагин, добавляющий задачи жизненного цикла (clean, assemble, check).

Пример:

plugins {
    id 'base'
}

В памяти: Легковесный, добавляет минимальное количество задач.

java-library:
Расширяет java, добавляя конфигурации api и implementation для библиотек.

Пример:

plugins {
    id 'java-library'
}
dependencies {
    api 'org.apache.commons:commons-lang3:3.12.0'
}

В памяти: Увеличивает граф зависимостей за счет дополнительных конфигураций.

checkstyle:
Интегрирует проверку стиля кода с помощью Checkstyle.

Пример:

plugins {
    id 'checkstyle'
}
checkstyle {
    toolVersion = '8.45'
    configFile = file('config/checkstyle/checkstyle.xml')
}

В памяти: Загружает конфигурацию Checkstyle и отчеты, увеличивая потребление памяти (50-100 МБ для крупных проектов).

maven-publish:
Позволяет публиковать артефакты в Maven-репозитории.

Пример:

plugins {
    id 'maven-publish'
}
publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
    repositories {
        maven {
            url 'https://nexus.example.com/repository/maven-releases'
        }
    }
}

В памяти: Загружает метаданные публикации и артефакты, увеличивая overhead при публикации.

#Java #middle #Gradle #Task #Plugin

Плагины для Kotlin, Android

Kotlin:
Плагин org.jetbrains.kotlin.jvm для JVM-проектов или org.jetbrains.kotlin.android для Android.

Пример:

plugins {
    id 'org.jetbrains.kotlin.jvm' version '1.9.0'
}
dependencies {
    implementation 'org.jetbrains.kotlin:kotlin-stdlib:1.9.0'
}

В памяти: Загружает Kotlin-компилятор и зависимости, добавляя 100-200 МБ overhead.

Android:
Плагин com.android.application или com.android.library для Android-проектов.

Пример:

plugins {
    id 'com.android.application' version '8.1.0'
    id 'org.jetbrains.kotlin.android' version '1.9.0'
}
android {
    compileSdk 33
    defaultConfig {
        applicationId 'com.example.app'
        minSdk 21
        targetSdk 33
        versionCode 1
        versionName '1.0'
    }
}

В памяти: Android-плагины загружают Android SDK, инструменты сборки (dexer, aapt2) и зависимости, что может потребовать 500-1000 МБ памяти.

Создание собственных плагинов

Собственные плагины позволяют кастомизировать сборку. Они могут быть написаны на Groovy, Kotlin или Java.

Плагин на Groovy
Создайте проект с структурой:

my-plugin/
├── src/main/groovy/com/example/MyPlugin.groovy
├── build.gradle

Реализуйте плагин:

package com.example
import org.gradle.api.Plugin
import org.gradle.api.Project

class MyPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.tasks.register('myTask') {
            doLast {
                println 'Hello from MyPlugin!'
            }
        }
    }
}

Настройте build.gradle:

plugins {
    id 'groovy'
    id 'maven-publish'
}
group = 'com.example'
version = '1.0'
publishing {
    publications {
        maven(MavenPublication) {
            from components.java
        }
    }
}

Опубликуйте:

./gradlew publish.

В памяти: Groovy-плагины загружают Groovy-библиотеки, добавляя 50-100 МБ overhead.

Плагин на Kotlin

Создайте проект:

my-plugin/
├── src/main/kotlin/com/example/MyPlugin.kt
├── build.gradle.kts

Реализуйте плагин:

package com.example
import org.gradle.api.Plugin
import org.gradle.api.Project

class MyPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.tasks.register("myTask") {
            doLast {
                println("Hello from MyPlugin!")
            }
        }
    }
}

Настройте build.gradle.kts:

plugins {
    `kotlin-dsl`
    `maven-publish`
}
group = "com.example"
version = "1.0"
publishing {
    publications {
        create<MavenPublication>("maven") {
            from(components["java"])
        }
    }
}

Опубликуйте:

./gradlew publish.

В памяти: Kotlin-плагины загружают Kotlin-библиотеки, добавляя 50-100 МБ overhead, но обеспечивают строгую типизацию.

Плагин на Java
Аналогично, но используйте Java-классы:

package com.example;
import org.gradle.api.Plugin;
import org.gradle.api.Project;

public class MyPlugin implements Plugin<Project> {
    @Override
    public void apply(Project project) {
        project.getTasks().register("myTask", task -> {
            task.doLast(t -> System.out.println("Hello from MyPlugin!"));
        });
    }
}

В памяти: Java-плагины легче, чем Groovy/Kotlin, так как не требуют дополнительных библиотек DSL.

Публикация плагина
Опубликуйте в локальный репозиторий:

./gradlew publishToMavenLocal

Используйте в другом проекте:

plugins {
    id 'com.example.my-plugin' version '1.0'
}

#Java #middle #Gradle #Task #Plugin

Gradle Plugin Portal

Gradle Plugin Portal (plugins.gradle.org) — центральный репозиторий для публикации и загрузки плагинов.

Публикация:
Зарегистрируйтесь на plugins.gradle.org.
Получите API-ключ.

Настройте build.gradle:

plugins {
    id 'com.gradle.plugin-publish' version '1.2.0'
}
pluginBundle {
    plugins {
        myPlugin {
            id = 'com.example.my-plugin'
            displayName = 'My Plugin'
            description = 'A custom Gradle plugin'
            tags = ['custom', 'example']
            version = '1.0'
        }
    }
}

Опубликуйте:

./gradlew publishPlugins.

Использование:

plugins {
    id 'com.example.my-plugin' version '1.0'
}

В памяти: Gradle Plugin Portal загружает метаданные плагинов в память при разрешении, добавляя небольшой overhead (10-50 МБ).

Plugin Resolution Strategy

Gradle разрешает плагины из репозиториев, указанных в pluginManagement или buildscript.

Стратегия разрешения:
Поиск: Gradle ищет плагин в Gradle Plugin Portal, Maven Central или пользовательских репозиториях.
Конфликты: Если плагин доступен в нескольких версиях, Gradle выбирает новейшую или указанную версию.

Настройка:

configurations.all {
    resolutionStrategy {
        force 'com.example:my-plugin:1.0'
    }
}

В памяти: Разрешение плагинов загружает их метаданные и зависимости в память, аналогично зависимостям проекта.

pluginManagement в settings.gradle

Блок pluginManagement в settings.gradle позволяет централизованно управлять плагинами для всех модулей.

Пример:

pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
    }
    plugins {
        id 'org.springframework.boot' version '2.7.18'
    }
}

Kotlin DSL:

pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
    }
    plugins {
        id("org.springframework.boot") version "2.7.18"
    }
}

Назначение:
Указывает репозитории для плагинов.
Фиксирует версии плагинов для всех модулей.

Поддерживает кастомные разрешения:

pluginManagement {
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == 'com.example.my-plugin') {
                useModule('com.example:my-plugin:1.0')
            }
        }
    }
}

В памяти: pluginManagement загружает метаданные плагинов во время инициализации, добавляя минимальный overhead (10-30 МБ), но обеспечивая согласованность версий.

Нюансы и внутренние механизмы

Управление памятью:
Плагины загружаются как Java-классы в JVM, включая их зависимости. Крупные плагины (например, android) могут добавлять 500-1000 МБ overhead.
Скриптовые плагины парсятся как Groovy/Kotlin-скрипты, увеличивая потребление памяти из-за динамической компиляции.
Оптимизируйте с помощью pluginManagement для централизованного управления и минимизации дублирования.

Кэширование:
Плагины и их зависимости кэшируются в ~/.gradle/caches/modules-2, снижая сетевые запросы.
Очистка кэша:

rm -rf ~/.gradle/caches.

Производительность:
plugins {} быстрее, чем apply plugin:, за счет оптимизированного разрешения.
Параллельное выполнение задач (--parallel) ускоряет сборку, но увеличивает пиковое потребление памяти.
Используйте --configure-on-demand для сокращения времени конфигурации.

Отладка:
Используйте --info или --debug для анализа загрузки плагинов:

./gradlew build --debug

Проверьте список задач:

./gradlew tasks --all.

Build Scans (--scan) показывают влияние плагинов на сборку.

Совместимость:
Убедитесь, что плагины совместимы с версией Gradle (например, Android-плагины требуют Gradle 7.0+).
Используйте JAVA_HOME с JDK 8+ (рекомендуется 11+).

Безопасность:
Храните учетные данные для репозиториев в ~/.gradle/gradle.properties с ограниченными правами (chmod 600).
Проверяйте плагины из Gradle Plugin Portal на наличие GPG-подписей.

#Java #middle #Gradle #Task #Plugin

Модульность и многомодульные проекты в Gradle

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

Преимущества:
Разделение функциональности на независимые модули (например, API, ядро, реализация).
Упрощение тестирования и поддержки.
Параллельная сборка модулей для повышения производительности.
Повторное использование конфигураций и зависимостей.

В памяти: Каждый модуль создает собственный объект Project в модели Gradle, увеличивая потребление памяти пропорционально количеству модулей (обычно 50-100 МБ на модуль). Граф задач (DAG) для всех модулей хранится в памяти, что может достигать 1-2 ГБ для крупных проектов.

settings.gradle(.kts) — управление include-проектами
Файл settings.gradle (или settings.gradle.kts) определяет структуру многомодульного проекта, включая корневое имя и подмодули.

Основные функции:
Указание имени корневого проекта: rootProject.name.
Включение подмодулей через include.
Настройка репозиториев и плагинов через pluginManagement.

Пример (Groovy DSL):

rootProject.name = 'my-project'
include 'module-api', 'module-core', 'module-web'

Kotlin DSL:

rootProject.name = "my-project"
include("module-api", "module-core", "module-web")

Нюансы:

Каждый подмодуль должен иметь собственный build.gradle в папке с таким же именем (например, module-api/build.gradle).
Подмодули могут быть вложенными:include 'module-core:submodule'

В памяти: settings.gradle загружается на фазе инициализации, создавая модель проекта с объектами Project для каждого модуля. Это минимальная фаза по потреблению памяти (50-100 МБ), но сложные настройки (например, pluginManagement) могут увеличить overhead.

Структура multi-module проекта: Parent + Children

Многомодульный проект состоит из корневого (parent) проекта и подмодулей (children), каждый из которых имеет собственный build.gradle.

Пример структуры:

my-project/
├── build.gradle
├── settings.gradle
├── module-api/
│   └── build.gradle
├── module-core/
│   └── build.gradle
├── module-web/
│   └── build.gradle

Parent проект:
Корневой build.gradle задает общие настройки, плагины и зависимости для всех подмодулей.

Пример:

allprojects {
    repositories {
        mavenCentral()
    }
}
subprojects {
    apply plugin: 'java'
    dependencies {
        testImplementation 'junit:junit:4.13.2'
    }
}

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

Пример (module-api/build.gradle):

plugins {
    id 'java-library'
}
dependencies {
    api 'org.apache.commons:commons-lang3:3.12.0'
}

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

Для оптимизации используйте --configure-on-demand:

./gradlew build --configure-on-demand

Project Access: project(":module")

Подмодули доступны через объект project с использованием их пути, определенного в settings.gradle.

Пример:

dependencies {
    implementation project(':module-core')
}

Это добавляет module-core как зависимость для текущего модуля.

Нюансы:
Путь начинается с : для корневого проекта (например, :module-core:submodule для вложенных модулей).
Доступ к свойствам другого модуля:println project(':module-core').version

В памяти: Gradle хранит все объекты Project в памяти, обеспечивая доступ через project(). Это увеличивает модель проекта, особенно для больших иерархий модулей.

#Java #middle #Gradle #Task #include_projects

Sharing Logic между проектами

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

Common Logic

В корневом build.gradle:
Используйте блоки allprojects и subprojects для общих настроек:

subprojects {
    apply plugin: 'java'
    version = '1.0.0'
    repositories {
        mavenCentral()
    }
}

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

Создайте файл common.gradle:

apply plugin: 'java'
dependencies {
    testImplementation 'junit:junit:4.13.2'
}

Подключите в подмодулях:

apply from: "$rootDir/gradle/common.gradle"

Кастомные плагины:
Создайте плагин для общей логики (см. раздел "Создание собственных плагинов" в предыдущей статье).

Пример применения:

subprojects {
    apply plugin: 'com.example.common-plugin'
}

В памяти: Общая логика уменьшает дублирование кода, но увеличивает сложность модели проекта, так как Gradle загружает и парсит дополнительные скрипты или плагины.

Version Catalogs (libs.versions.toml)

Version Catalogs — это централизованный способ управления версиями зависимостей и плагинов, введенный в Gradle 7.0.

Настройка (gradle/libs.versions.toml):

[versions]
spring-boot = "2.7.18"
junit = "4.13.2"

[libraries]
spring-core = { group = "org.springframework", name = "spring-core", version.ref = "spring-boot" }
junit = { group = "junit", name = "junit", version.ref = "junit" }

[plugins]
spring-boot = { id = "org.springframework.boot", version.ref = "spring-boot" }

Использование:

plugins {
    alias(libs.plugins.spring.boot)
}
dependencies {
    implementation libs.spring.core
    testImplementation libs.junit
}

Kotlin DSL:

plugins {
    alias(libs.plugins.spring.boot)
}
dependencies {
    implementation(libs.spring.core)
    testImplementation(libs.junit)
}

Преимущества:
Централизованное управление версиями.
Улучшенная читаемость и автодополнение в IDE.
Упрощение обновления версий.

В памяти: Version Catalog загружается как часть модели проекта, добавляя минимальный overhead (10-20 МБ), но упрощает управление зависимостями, снижая вероятность конфликтов.

#Java #middle #Gradle #Task #include_projects

Сценарии и практики разделения: Core/Api/Impl

Разделение проекта на модули (Core, Api, Impl) — распространенная практика в корпоративной разработке для обеспечения модульности и повторного использования.

Core:
Содержит общую бизнес-логику, утилиты, модели данных.

Пример:

module-core/build.gradle:plugins {
    id 'java-library'
}
dependencies {
    implementation 'org.apache.commons:commons-lang3:3.12.0'
}

Api:
Определяет публичные интерфейсы, DTO или контракты.

Пример:

module-api/build.gradle:plugins {
    id 'java-library'
}
dependencies {
    api project(':module-core')
}

Impl:
Реализует интерфейсы из Api, добавляя конкретную функциональность.

Пример: module-impl/build.gradle:

plugins {
    id 'java'
}
dependencies {
    implementation project(':module-api')
}

Структура:

my-project/
├── module-core/
│   └── build.gradle
├── module-api/
│   └── build.gradle
├── module-impl/
│   └── build.gradle
├── build.gradle
├── settings.gradle

Практики:
Используйте api в модуле module-api для экспорта публичных интерфейсов.
Минимизируйте зависимости между модулями, чтобы избежать циклических зависимостей.
Централизуйте версии через Version Catalog или dependencyManagement в корневом build.gradle.

В памяти: Каждый модуль добавляет объект Project, задачи и зависимости в модель Gradle, увеличивая потребление памяти. Разделение на Core/Api/Impl уменьшает размер каждого модуля, но увеличивает общее количество объектов в памяти.

Gradle Composite Builds

Composite Builds позволяют включать другие Gradle-проекты как зависимости, без необходимости публикации в репозиторий.

Настройка:
В settings.gradle корневого проекта:

includeBuild '../other-project'

В build.gradle используйте проект как зависимость:

dependencies {
    implementation project(':other-project:module-x')
}

Использование:
Полезно для разработки связанных проектов, находящихся в разных репозиториях.
Gradle автоматически разрешает зависимости между проектами.

В памяти: Composite Builds загружают модели всех включенных проектов в память, значительно увеличивая overhead (100-500 МБ на проект). Используйте с осторожностью для крупных систем.

Процесс сборки с помощью task-graph (Task Avoidance, Parallel Build)

Gradle строит граф задач (Directed Acyclic Graph, DAG) для определения порядка выполнения задач в многомодульных проектах.

Task Avoidance:
Gradle использует инкрементальную сборку, пропуская задачи, чьи входные/выходные данные не изменились (up-to-date checks).

Пример:

tasks.named('compileJava') {
    inputs.files('src/main/java')
    outputs.dir('build/classes/java/main')
}

В памяти: Gradle хранит хэши входов/выходов в памяти и ~/.gradle/caches, добавляя небольшой overhead (10-50 МБ).

Parallel Build:
Gradle поддерживает параллельное выполнение задач с флагом --parallel:

./gradlew build --parallel

#Java #middle #Gradle #Task #include_projects

Конфигурация, профили, параметры и свойства в Gradle: Управление сборкой

Системные свойства, переменные окружения

Gradle поддерживает настройку через системные свойства и переменные окружения, которые задают параметры JVM и сборки.

Системные свойства:
Задаются через -D в командной строке или в gradle.properties.

Пример:

./gradlew build -Dorg.gradle.jvmargs=-Xmx2048m

Доступ в build.gradle:

println System.getProperty('org.gradle.jvmargs')

Переменные окружения:
Доступны через System.getenv().

Пример:

println System.getenv('JAVA_HOME')

Полезны для передачи внешних параметров (например, API-ключи, пути).

Приоритет:
Системные свойства (-D) > gradle.properties > переменные окружения.

В памяти: Системные свойства и переменные окружения загружаются как часть конфигурации JVM, добавляя минимальный overhead (менее 10 МБ). Gradle кэширует их значения в модели проекта.

Нюансы:
Используйте переменные окружения для чувствительных данных с осторожностью, предпочтительно шифруйте их.

Проверяйте наличие переменных:

if (System.getenv('CI')) {
    println 'Running in CI environment'
}

gradle.properties: Project-level, global (~/.gradle)

Файл gradle.properties используется для определения свойств Gradle, JVM и проекта.

Project-level (projectDir/gradle.properties):
Применяется к конкретному проекту.

Пример:

version=1.0.0
org.gradle.jvmargs=-Xmx2048m
org.gradle.parallel=true

Global (~/.gradle/gradle.properties):
Применяется ко всем проектам на машине.

Пример:

org.gradle.caching=true
org.gradle.jvmargs=-Xmx4096m

Использование:
Свойства доступны через project.property:println project.version

В памяти: Свойства загружаются как часть модели проекта на фазе инициализации, добавляя минимальный overhead (5-10 МБ). Глобальный gradle.properties парсится для всех сборок, увеличивая время инициализации.

Нюансы:
Храните чувствительные данные (например, ключи API) в ~/.gradle/gradle.properties с ограниченными правами (chmod 600).
Используйте для централизованных настроек, таких как JVM-память или включение кэширования.


Использование -P, -D, --info, --debug, --scan

Gradle предоставляет командные параметры для настройки и отладки сборки.

-P:
Задает свойства проекта.

Пример:

./gradlew build -PmyProperty=value

Доступ:

println project.hasProperty('myProperty') ? project.myProperty : 'default'

-D:
Задает системные свойства JVM.

Пример:

./gradlew build -Dorg.gradle.jvmargs=-Xmx2048m

--info:
Выводит информационные логи.

Пример:

./gradlew build --info

--debug:
Выводит подробные логи для отладки.

Пример:

./gradlew build --debug

--scan:
Генерирует Build Scan для анализа сборки.

Пример:

./gradlew build --scan

Требует настройки плагина:

plugins {
    id 'com.gradle.build-scan' version '3.17.4'
}
buildScan {
    termsOfServiceUrl = 'https://gradle.com/terms-of-service'
    termsOfServiceAgree = 'yes'
}

В памяти: Параметры -P и -D добавляют свойства в модель проекта или JVM, минимально влияя на память. Логи --info и --debug увеличивают объем вывода, а --scan загружает метаданные сборки в память (50-100 МБ для крупных проектов).

Нюансы:
Используйте --scan для анализа производительности и выявления узких мест.
Параметры -P и -D имеют приоритет над gradle.properties.


Lazy vs Eager Configuration

Gradle поддерживает два подхода к конфигурации: eager (немедленная) и lazy (ленивая).

Eager Configuration:
Вычисления выполняются на фазе конфигурации, даже если задача не выполняется.

Пример:

task example {
    def value = computeExpensiveValue()
    doLast {
        println value
    }
}

Lazy Configuration:
Вычисления откладываются до фазы выполнения с использованием Provider или Property.

Пример:

task example {
    def value = providers.provider { computeExpensiveValue() }
    doLast {
        println value.get()
    }
}

В памяти: Ленивая конфигурация снижает потребление памяти на фазе конфигурации, так как значения вычисляются только при необходимости. Eager-конфигурация загружает все значения сразу, увеличивая overhead (до 100-200 МБ для сложных скриптов).

#Java #middle #Gradle #Task #deploy

Конфигурационные API: Provider, Property, ListProperty

Gradle предоставляет API для ленивой конфигурации, что улучшает производительность и гибкость.

Provider:
Интерфейс для ленивых значений, вычисляемых при необходимости.

Пример:

def versionProvider = providers.provider { project.version }
task printVersion {
    doLast {
        println "Version: ${versionProvider.get()}"
    }
}

Property:
Для управления одиночными значениями.

Пример:

task example {
    def outputFile = objects.property(String)
    outputFile.set('build/output.txt')
    doLast {
        println "Output: ${outputFile.get()}"
    }
}

ListProperty:
Для управления списками значений.

Пример:

task example {
    def files = objects.listProperty(String)
    files.set(['file1.txt', 'file2.txt'])
    doLast {
        files.get().each { println it }
    }
}

Kotlin DSL:

tasks.register("example") {
    val outputFile = objects.property<String>()
    outputFile.set("build/output.txt")
    doLast {
        println("Output: ${outputFile.get()}")
    }
}

В памяти: Provider, Property и ListProperty хранят ссылки на значения, а не сами значения, минимизируя потребление памяти до фазы выполнения. Это снижает overhead на фазе конфигурации (экономия 10-50 МБ на задачу).

Нюансы:
Используйте Provider для динамических вычислений.
Property и ListProperty обеспечивают строгую типизацию, особенно в Kotlin DSL.


Ext-переменные (ext {})

Блок ext позволяет определять пользовательские свойства для проекта или объектов.

Пример:

ext {
    myVersion = '1.0.0'
    myProperty = 'value'
}
task printExt {
    doLast {
        println project.ext.myVersion
    }
}

Kotlin DSL:

extra["myVersion"] = "1.0.0"
extra["myProperty"] = "value"
tasks.register("printExt") {
    doLast {
        println(project.extra["myVersion"])
    }
}

Использование:
Для хранения общих констант (например, версий зависимостей).
Для передачи данных между задачами или модулями.

В памяти: ext-переменные хранятся как часть модели проекта, добавляя минимальный overhead (менее 10 МБ). Однако большое количество переменных может усложнить модель.

Нюансы:
Избегайте чрезмерного использования ext в пользу Version Catalog для версий зависимостей.
Используйте для кастомных настроек, не связанных с зависимостями.


buildSrc/ директория

Директория buildSrc позволяет определять кастомную логику (плагины, задачи) в проекте.

Структура:

my-project/
├── buildSrc/
│   ├── src/main/groovy/com/example/MyPlugin.groovy
│   ├── build.gradle
├── build.gradle
├── settings.gradle

Пример плагина (buildSrc/src/main/groovy/com/example/MyPlugin.groovy):

package com.example

import org.gradle.api.Plugin
import org.gradle.api.Project

class MyPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.tasks.register('myTask') {
            doLast {
                println 'Hello from buildSrc plugin!'
            }
        }
    }
}

Настройка (buildSrc/build.gradle):

plugins {
    id 'groovy'
}

Использование:

apply plugin: 'com.example.my-plugin'

Kotlin DSL:
Создайте buildSrc/src/main/kotlin/com/example/MyPlugin.kt:

package com.example

import org.gradle.api.Plugin
import org.gradle.api.Project

class MyPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.tasks.register("myTask") {
            doLast {
                println("Hello from buildSrc plugin!")
            }
        }
    }
}

Настройте buildSrc/build.gradle.kts:

plugins {
    `kotlin-dsl`
}

В памяти: buildSrc компилируется как отдельный проект, добавляя собственный classpath и зависимости в JVM. Это увеличивает потребление памяти (100-200 МБ), особенно если buildSrc включает сложные плагины.

Нюансы:
buildSrc автоматически доступен всем модулям проекта.
Используйте для кастомных задач и плагинов, специфичных для проекта.
Для повторно используемых плагинов предпочтительнее создавать отдельный проект и публиковать в репозиторий.


#Java #middle #Gradle #Task #deploy

Shared Build Logic через init-скрипты

Init-скрипты позволяют задавать глобальную логику, применяемую ко всем Gradle-сборкам.

Настройка:

Создайте файл ~/.gradle/init.d/my-init.gradle:

allprojects {
    repositories {
        mavenCentral()
    }
}
gradle.projectsLoaded {
    rootProject.tasks.register('globalTask') {
        doLast {
            println 'Global task from init script'
        }
    }
}

Kotlin DSL (~/.gradle/init.d/my-init.gradle.kts):

allprojects {
    repositories {
        mavenCentral()
    }
}
gradle.projectsLoaded {
    rootProject.tasks.register("globalTask") {
        doLast {
            println("Global task from init script")
        }
    }
}

Использование:
Init-скрипты автоматически применяются ко всем проектам.

Можно указать скрипт явно:

./gradlew build --init-script my-init.gradle

В памяти: Init-скрипты загружаются на фазе инициализации, добавляя задачи и конфигурации в модель проекта. Это увеличивает overhead (10-50 МБ), но распределяется между всеми сборками.

Нюансы:
Используйте для глобальных настроек (например, репозитории, JVM-параметры).
Избегайте сложной логики, чтобы не замедлять инициализацию.


Gradle Wrapper (gradlew): настройка и версионирование

Gradle Wrapper (gradlew) — это скрипт, обеспечивающий воспроизводимость сборки с фиксированной версией Gradle.

Настройка:
Сгенерируйте Wrapper:

gradle wrapper --gradle-version 8.1

Создает файлы:

my-project/
├── gradlew
├── gradlew.bat
├── gradle/
│   └── wrapper/
│       ├── gradle-wrapper.jar
│       ├── gradle-wrapper.properties

gradle-wrapper.properties:

distributionUrl=https\://services.gradle.org/distributions/gradle-8.1-bin.zip

Использование:
Запускайте сборку через Wrapper:

./gradlew build

Wrapper загружает указанную версию Gradle, если она отсутствует в ~/.gradle/wrapper.

Версионирование:

Обновите версию:

./gradlew wrapper --gradle-version 8.2

Используйте конкретную версию для согласованности в CI/CD.

В памяти: Wrapper загружает Gradle в отдельный JVM-процесс, добавляя базовый overhead (200-300 МБ). Кэширование дистрибутива в ~/.gradle/wrapper минимизирует сетевые запросы.

Нюансы:
Всегда включайте Wrapper в репозиторий для воспроизводимости.
Проверяйте целостность distributionUrl для безопасности (используйте HTTPS).
Настройте прокси в gradle-wrapper.properties, если требуется:systemProp.http.proxyHost=proxy.example.com
systemProp.http.proxyPort=8080


#Java #middle #Gradle #Task #deploy

Интеграции, публикации в Gradle

Публикация артефактов

Gradle поддерживает публикацию артефактов (JAR, WAR, и т.д.) в репозитории с помощью плагина maven-publish.
maven-publish, publishing {}

Плагин maven-publish:
Позволяет публиковать артефакты в Maven-совместимые репозитории.

Пример (build.gradle):

plugins {
    id 'java'
    id 'maven-publish'
}
publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
            groupId = 'com.example'
            artifactId = 'my-library'
            version = '1.0.0'
        }
    }
    repositories {
        maven {
            url 'https://nexus.example.com/repository/maven-releases'
            credentials {
                username = project.findProperty('nexusUsername')
                password = project.findProperty('nexusPassword')
            }
        }
    }
}

Kotlin DSL:

plugins {
    java
    `maven-publish`
}
publishing {
    publications {
        create<MavenPublication>("mavenJava") {
            from(components["java"])
            groupId = "com.example"
            artifactId = "my-library"
            version = "1.0.0"
        }
    }
    repositories {
        maven {
            url = uri("https://nexus.example.com/repository/maven-releases")
            credentials {
                username = project.findProperty("nexusUsername") as String?
                password = project.findProperty("nexusPassword") as String?
            }
        }
    }
}

Команда публикации:

./gradlew publish

В памяти: Публикация загружает метаданные артефактов (POM-файлы, JAR) и зависимости в память, добавляя 50-100 МБ overhead. Сетевые операции для загрузки в репозиторий увеличивают время выполнения.

Нюансы:
Храните учетные данные в ~/.gradle/gradle.properties:

nexusUsername=myuser
nexusPassword=mypassword

Используйте HTTPS для безопасной публикации.


Подпись: GPG и signing

Плагин signing:
Добавляет подпись артефактов с помощью GPG для проверки их целостности.

Пример:

plugins {
    id 'java'
    id 'maven-publish'
    id 'signing'
}
signing {
    sign publishing.publications.mavenJava
}
publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

Настройка GPG:

Установите GPG и сгенерируйте ключ:

gpg --gen-key

Настройте ~/.gradle/gradle.properties:

signing.keyId=12345678
signing.password=yourpassword
signing.secretKeyRingFile=/path/to/.gnupg/secring.gpg

В памяти: Подпись добавляет операции шифрования, увеличивая потребление памяти (10-50 МБ) и время выполнения задачи.

Нюансы:
Публикуйте публичный ключ в keyserver (например, gpg --send-keys 12345678).
Для Maven Central подпись обязательна.


Интеграция с Maven Central, Artifactory, Nexus

Maven Central:
Используйте плагин io.github.gradle-nexus.publish-plugin для упрощения публикации:

plugins {
    id 'io.github.gradle-nexus.publish-plugin' version '1.3.0'
}
nexusPublishing {
    repositories {
        sonatype {
            nexusUrl = uri('https://s01.oss.sonatype.org/service/local/')
            snapshotRepositoryUrl = uri('https://s01.oss.sonatype.org/content/repositories/snapshots/')
            username = project.findProperty('sonatypeUsername')
            password = project.findProperty('sonatypePassword')
        }
    }
}

Команда:

 ./gradlew publishToSonatype closeAndReleaseRepository.

Artifactory:
Настройте репозиторий:

publishing {
    repositories {
        maven {
            url 'https://artifactory.example.com/artifactory/libs-release'
            credentials {
                username = project.findProperty('artifactoryUsername')
                password = project.findProperty('artifactoryPassword')
            }
        }
    }
}

Nexus:
Аналогично Artifactory, укажите URL и учетные данные.

В памяти: Публикация в удаленные репозитории загружает метаданные и артефакты в память, а также выполняет сетевые операции, увеличивая overhead (50-200 МБ).

#Java #middle #Gradle #Task #integration

CI/CD

Gradle легко интегрируется с CI/CD системами, такими как Jenkins, GitLab CI и GitHub Actions, обеспечивая автоматизацию сборки, тестирования и публикации.

Gradle в Jenkins

Настройка:
Установите Gradle Plugin в Jenkins.

Создайте задачу с Gradle Wrapper:

./gradlew clean build --no-daemon

Настройте gradle.properties для CI:

org.gradle.jvmargs=-Xmx2048m
org.gradle.caching=true

В памяти: Используйте --no-daemon в CI, чтобы избежать постоянного процесса Gradle Daemon, экономя память (200-300 МБ).

GitLab CI

Пример

.gitlab-ci.yml:
stages:
  - build
build:
  stage: build
  image: gradle:8.1-jdk11
  script:
    - ./gradlew clean build --no-daemon
  cache:
    paths:
      - ~/.gradle/caches/
      - ~/.gradle/wrapper/

В памяти: Кэширование ~/.gradle/caches между сборками снижает сетевые запросы, но требует дискового пространства.

GitHub Actions

Пример

 .github/workflows/build.yml:
name: Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: gradle/gradle-build-action@v2
        with:
          gradle-version: 8.1
      - run: ./gradlew clean build --no-daemon

В памяти: GitHub Actions кэширует зависимости через gradle-build-action, минимизируя overhead.

Нюансы:
Используйте --no-daemon в CI для экономии памяти.

Включите Build Cache для ускорения:

buildCache {
    local { enabled = true }
}

Публикуйте Build Scans для анализа CI-сборок.


Gradle Daemon и производительность

Gradle Daemon — это фоновый процесс, который сохраняет JVM между сборками для ускорения.

Включение:
По умолчанию включен.

Отключение:

./gradlew build --no-daemon.

Производительность:
Ускоряет повторные сборки, избегая инициализации JVM.
Поддерживает --parallel для параллельного выполнения задач.

В памяти: Daemon потребляет 200-300 МБ памяти в простое. Для крупных проектов может достигать 1-2 ГБ при активной сборке.

Нюансы:
Используйте --no-daemon в CI/CD, чтобы избежать утечек памяти.

Остановите Daemon:

 ./gradlew --stop.

Настройте память в gradle.properties:

org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m

Build Scan: анализ, оптимизация, диагностика

Build Scans — это веб-отчеты, предоставляющие детальную информацию о сборке.

Настройка:

plugins {
    id 'com.gradle.build-scan' version '3.17.4'
}
buildScan {
    termsOfServiceUrl = 'https://gradle.com/terms-of-service'
    termsOfServiceAgree = 'yes'
}

Генерация:

./gradlew build --scan

Использование:
Анализ времени выполнения задач.
Выявление узких мест (медленные задачи, конфликты зависимостей).
Диагностика ошибок через логи и зависимости.

В памяти: Build Scan загружает метаданные сборки (граф задач, зависимости, время выполнения) в память, добавляя 50-100 МБ overhead. Данные отправляются на сервер Gradle Enterprise, требуя сетевых операций.

Нюансы:
Полезен для оптимизации CI/CD и крупных проектов.
Храните ссылки на Build Scans для командной работы.


#Java #middle #Gradle #Task #integration