Конфигурационные 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