Настройка клиента

OkHttpClient.Builder позволяет настраивать параметры клиента, такие как таймауты, пул соединений и интерсепторы.

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(30, TimeUnit.SECONDS)
    .writeTimeout(30, TimeUnit.SECONDS)
    .build();

Для отключения перенаправлений:

OkHttpClient client = new OkHttpClient.Builder()
    .followRedirects(false)
    .build();

Загрузка файлов

OkHttp поддерживает загрузку файлов с помощью MultipartBody:

File file = new File("src/test/resources/test.txt");
RequestBody fileBody = RequestBody.create(MediaType.parse("application/octet-stream"), file);
RequestBody requestBody = new MultipartBody.Builder()
    .setType(MultipartBody.FORM)
    .addFormDataPart("file", file.getName(), fileBody)
    .build();

Request request = new Request.Builder()
    .url("https://api.example.com/upload")
    .post(requestBody)
    .build();

Для отслеживания прогресса загрузки можно создать кастомный RequestBody:

public class ProgressRequestWrapper extends RequestBody {
    private final RequestBody requestBody;
    private final ProgressListener listener;

    public ProgressRequestWrapper(RequestBody requestBody, ProgressListener listener) {
        this.requestBody = requestBody;
        this.listener = listener;
    }

    @Override
    public MediaType contentType() {
        return requestBody.contentType();
    }

    @Override
    public void writeTo(BufferedSink sink) throws IOException {
        CountingSink countingSink = new CountingSink(sink, this, contentLength());
        BufferedSink bufferedSink = Okio.buffer(countingSink);
        requestBody.writeTo(bufferedSink);
        bufferedSink.flush();
    }

    public interface ProgressListener {
        void update(long bytesWritten, long contentLength, boolean done);
    }
}

Отмена запросов

Запросы можно отменить с помощью метода Call.cancel():

Call call = client.newCall(request);
ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
executor.schedule(() -> {
    call.cancel();
    System.out.println("Request cancelled");
}, 1, TimeUnit.SECONDS);

Кэширование

Для настройки кэша:

File cacheDirectory = new File("src/test/resources/cache");
int cacheSize = 10 * 1024 * 1024; // 10 MiB
Cache cache = new Cache(cacheDirectory, cacheSize);

OkHttpClient client = new OkHttpClient.Builder()
    .cache(cache)
    .build();

#Java #middle #on_request #OkHttp

Лучшие практики

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

Обработка больших ответов:
Избегайте использования response.body().string() для больших ответов. Вместо этого используйте byteStream() для потоковой обработки.

Обработка ошибок:
Реализуйте повторные попытки для преходящих ошибок (например, 503) с помощью интерсепторов.
Всегда закрывайте Response с помощью response.close() или try-with-resources.

Безопасность:
Регулярно обновляйте OkHttp для получения последних исправлений безопасности.
Используйте привязку сертификатов для защиты от атак типа "человек посередине".

Асинхронные вызовы:
Предпочитайте асинхронные вызовы для Android-приложений, чтобы избежать блокировки UI-потока.


Интеграция с другими библиотеками

OkHttp часто используется в связке с другими библиотеками:

Retrofit: Упрощает создание RESTful API, используя OkHttp как базовый HTTP-клиент.

OkHttpClient client = new OkHttpClient.Builder()
    .addInterceptor(new LoggingInterceptor())
    .build();

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .client(client)
    .addConverterFactory(GsonConverterFactory.create())
    .build();

Moshi/Gson: Для сериализации и десериализации JSON.
HttpLoggingInterceptor: Для логирования HTTP-запросов и ответов.


Тестирование

OkHttp предоставляет MockWebServer для имитации серверных ответов в тестах:

MockWebServer server = new MockWebServer();
server.enqueue(new MockResponse().setBody("Hello, world!"));
server.start();

HttpUrl baseUrl = server.url("/test");
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder().url(baseUrl).build();
Response response = client.newCall(request).execute();

assertEquals("Hello, world!", response.body().string());
server.shutdown();

Для добавления MockWebServer в проект:

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>mockwebserver</artifactId>
    <version>5.1.0</version>
    <scope>test</scope>
</dependency>

Требования и зависимости

Версии: OkHttp 5.x поддерживает Android 5.0+ (API 21+) и Java 8+. Для более старых платформ используйте ветку 3.12.x (Android 2.3+, Java 7+).
Зависимости: Okio и стандартная библиотека Kotlin. Опционально: Conscrypt для улучшенной TLS-поддержки.

Maven:

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>5.1.0</version>
</dependency>

Для управления версиями рекомендуется использовать BOM:

<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp-bom</artifactId>
    <version>5.1.0</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

Поддержка GraalVM

OkHttp совместим с GraalVM Native Image, начиная с версии 5.0.0-alpha.2.

Пример сборки:

./gradlew okcurl:nativeImage
./okcurl/build/graal/okcurl https://httpbin.org/get

Безопасность
Для обеспечения безопасности регулярно обновляйте OkHttp, чтобы использовать последние исправления. Следите за историей конфигурации TLS на странице OkHttp.


#Java #middle #on_request #OkHttp

Задачи и жизненный цикл в Gradle


Task API: Task, DefaultTask, @TaskAction

Задачи (tasks) — это основная единица работы в Gradle, представляющая такие действия, как компиляция, тестирование или упаковка. Task API предоставляет инструменты для создания и настройки задач.


Основные компоненты

Task:
Интерфейс org.gradle.api.Task, определяющий базовую функциональность задачи (например, выполнение, зависимости).
Все задачи в Gradle реализуют этот интерфейс.

DefaultTask:
Класс org.gradle.api.DefaultTask, стандартная реализация интерфейса Task.
Используется для создания пользовательских задач.

Пример (Groovy DSL):

import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction

class CustomTask extends DefaultTask {
    @TaskAction
    void executeTask() {
        println 'Executing custom task'
    }
}

tasks.register('customTask', CustomTask)

@TaskAction:
Аннотация, указывающая метод, который выполняется при запуске задачи.

Пример (Kotlin DSL):

import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction

open class CustomTask : DefaultTask() {
    @TaskAction
    fun executeTask() {
        println("Executing custom task")
    }
}

tasks.register<CustomTask>("customTask")

В памяти: Каждая задача представлена как объект в JVM, содержащий метаданные (имя, зависимости, действия). Gradle загружает все задачи в память во время фазы конфигурации, что увеличивает потребление памяти пропорционально их количеству. Плагины, такие как java, добавляют множество задач (например, compileJava, test), увеличивая overhead.

Gradle Lifecycle

Жизненный цикл Gradle состоит из трех фаз: Initialization, Configuration и Execution. Каждая фаза выполняет определенные функции и влияет на производительность и память.

Initialization Phase:
Gradle загружает settings.gradle для определения структуры проекта (корневое имя, подмодули).
Создает объекты Project для корневого проекта и подпроектов.
Устанавливает начальные настройки, такие как репозитории и плагины.

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

Configuration Phase:
Gradle парсит все файлы build.gradle, создавая модель проекта и граф задач (Directed Acyclic Graph, DAG).
Все скрипты конфигурации выполняются, даже для задач, которые не будут запущены.
Пример: Определение зависимостей, задач и плагинов.

В памяти: Самая ресурсоемкая фаза, так как Gradle загружает и компилирует все скрипты, плагины и зависимости. Для крупных проектов может потребоваться 500-1000 МБ памяти.

Оптимизация: Используйте флаг --configure-on-demand для конфигурации только необходимых модулей:

./gradlew build --configure-on-demand

Execution Phase:
Gradle выполняет задачи, указанные в командной строке (например, ./gradlew build), в порядке, определенном DAG.
Инкрементальность пропускает задачи, чьи входные/выходные данные не изменились (см. ниже).

В памяти: Зависит от сложности задач. Например, compileJava загружает исходные файлы и зависимости, а test — тестовые классы и фреймворки. Параллельное выполнение (--parallel) увеличивает пиковое потребление памяти.

Нюансы:
Конфигурация выполняется всегда, что замедляет сборку, особенно для крупных проектов.
Gradle Daemon сохраняет JVM между сборками, ускоряя повторные запуски, но увеличивая базовое потребление памяти (200-300 МБ).
Используйте --no-daemon для одноразовых сборок:

./gradlew build --no-daemon

#Java #middle #Gradle #Task #Lifecycle

Task Graph, зависимости между задачами

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

Зависимости между задачами

dependsOn:
Указывает, что задача зависит от выполнения других задач.

Пример:

task compileJava {
    doLast { println 'Compiling Java' }
}
task test(dependsOn: compileJava) {
    doLast { println 'Running tests' }
}

Gradle выполнит compileJava перед test.

mustRunAfter:
Определяет порядок выполнения без строгой зависимости.

Пример:

task taskA {
    doLast { println 'Task A' }
}
task taskB {
    mustRunAfter 'taskA'
    doLast { println 'Task B' }
}

Если обе задачи выполняются, taskB будет после taskA, но taskB может выполняться отдельно.

finalizedBy:
Указывает задачу, которая выполняется после завершения текущей, даже при ошибке.

Пример:

task build {
    doLast { println 'Building' }
}
task cleanUp {
    doLast { println 'Cleaning up' }
}
build.finalizedBy cleanUp

В памяти: DAG задач хранится как структура данных в JVM, где каждая задача — объект с метаданными (зависимости, действия). Размер графа пропорционален количеству задач, что может увеличить потребление памяти до нескольких сотен МБ в крупных проектах.

Incremental Build и Up-to-Date Checks

Gradle оптимизирует производительность за счет инкрементальной сборки, пропуская задачи, чьи входные/выходные данные не изменились.

Механизм:
Gradle проверяет хэши входных (исходные файлы, свойства) и выходных данных (скомпилированные классы, JAR).
Если хэши совпадают, задача помечается как up-to-date и пропускается.

Пример вывода:

> Task :compileJava UP-TO-DATE

Пример настройки:

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

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

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

./gradlew build --info

Gradle Inputs/Outputs (Task Inputs/Outputs)

Задачи Gradle имеют входы и выходы, которые определяют, что влияет на выполнение задачи и что она производит.

Inputs:
Файлы, свойства или другие данные, от которых зависит задача.

Пример:

task processFiles {
    inputs.files fileTree('src/main/resources')
    doLast {
        println 'Processing files'
    }
}

Outputs:
Файлы или директории, создаваемые задачей.

Пример:

task generateReport {
    outputs.file file('build/report.txt')
    doLast {
        file('build/report.txt').text = 'Report content'
    }
}

В памяти: Gradle хранит метаданные входов/выходов в памяти и кэширует хэши в ~/.gradle/caches. Для задач с большим количеством файлов (например, compileJava) это увеличивает потребление памяти, так как Gradle сканирует файловую систему.

Нюансы:
Явно указывайте входы/выходы для кастомных задач, чтобы включить инкрементальность.

Используйте inputs.property для не-файловых входов:

task customTask {
    inputs.property 'version', project.version
    doLast { println "Version: ${project.version}" }
}

#Java #middle #Gradle #Task #Lifecycle

Do-first/do-last и ленивость (Provider, Property)

Gradle поддерживает гибкую настройку задач через doFirst и doLast, а также ленивую конфигурацию через Provider и Property.

doFirst и doLast:
doFirst: Добавляет действие в начало выполнения задачи.
doLast: Добавляет действие в конец выполнения задачи.

Пример:

task example {
    doFirst { println 'Starting task' }
    doLast { println 'Ending task' }
}

Ленивость (Provider, Property):
Gradle использует ленивую оценку для отсрочки вычислений до фазы выполнения.

Provider: Интерфейс для ленивых значений.def version = providers.provider { project.version }

task printVersion {
    doLast {
        println "Version: ${version.get()}"
    }
}

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

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

В памяти: doFirst и doLast добавляют действия как объекты в задачу, минимально увеличивая память. Ленивые Provider и Property хранят ссылки на значения, а не сами значения, что оптимизирует память до их вычисления в фазе выполнения.

Gradle Listeners и хуки

Gradle предоставляет хуки для мониторинга и настройки жизненного цикла и задач.

BuildListener:
Устаревший интерфейс для мониторинга событий сборки.

Пример:

gradle.buildFinished {
    println 'Build completed'
}

TaskExecutionListener:
Отслеживает выполнение задач.

Пример:

gradle.taskGraph.whenReady {
    println 'Task graph is ready'
}

Project.afterEvaluate:
Выполняется после фазы конфигурации.

Пример:

project.afterEvaluate {
    println 'Project configured'
}

В памяти: Хуки создают дополнительные объекты-слушатели в памяти, увеличивая overhead. Для крупных проектов с множеством слушателей это может добавить 10-50 МБ памяти.

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


Gradle Build Cache

Build Cache позволяет кэшировать результаты задач для повторного использования между сборками или машинами.

Настройка:

buildCache {
    local {
        enabled = true
    }
    remote(HttpBuildCache) {
        url = 'https://cache.example.com/'
        push = true
    }
}

Как работает:
Gradle кэширует выходные данные задач (например, скомпилированные классы, JAR) в ~/.gradle/caches/build-cache или на удаленном сервере.
При повторной сборке Gradle проверяет хэши входов/выходов и использует кэшированные результаты, если они совпадают.
Пример: Задача compileJava кэширует классы в build/classes.

Использование:
Включите кэш:

./gradlew build --build-cache

Очистка локального кэша:

rm -rf ~/.gradle/caches/build-cache

В памяти: Build Cache требует хранения хэшей и метаданных в памяти во время выполнения, что добавляет 50-100 МБ overhead. Удаленный кэш увеличивает сетевые операции, но снижает локальные вычисления.

Нюансы:
Настройте входы/выходы задач точно, чтобы кэш работал корректно.
Build Cache наиболее эффективен для CI/CD, где результаты задач переиспользуются между сборками.


#Java #middle #Gradle #Task #Lifecycle

Плагины и расширение функциональности в 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

Обзор JSON Web Tokens (JWT) в Java

JSON Web Tokens (JWT) — это стандарт для создания компактных, самодостаточных токенов, используемых для безопасной передачи информации между сторонами в виде JSON-объекта. JWT широко применяется для аутентификации и авторизации в веб-приложениях, особенно в REST API. В Java экосистема библиотек, таких как jjwt и java-jwt, предоставляет мощные инструменты для работы с JWT.


Структура JWT

JWT состоит из трех основных частей, разделенных точками (.):
Header — содержит метаданные о токене, такие как тип (typ: JWT) и алгоритм подписи (например, alg: HS256 или RS256).
Payload — содержит полезные данные (claims), такие как идентификатор пользователя (sub), время выпуска (iat), срок действия (exp) и кастомные данные.
Signature — подпись, созданная с использованием секретного ключа или пары ключей (для асимметричных алгоритмов), для проверки целостности и подлинности токена.

Каждая часть кодируется в Base64Url и объединяется в строку вида: Header.Payload.Signature.

Пример JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

Наиболее популярная библиотека для работы с JWT в Java — это io.jsonwebtoken:jjwt. Она поддерживает создание, парсинг и валидацию токенов с использованием различных алгоритмов подписи.

Установка зависимости

Добавьте зависимость в pom.xml для Maven:

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.12.6</version>
</dependency>

Создание JWT

Пример создания JWT с использованием HMAC-SHA256:

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import java.security.Key;
import java.util.Date;

public class JwtExample {
    public static String createJwt(String subject, long ttlMillis) {
        Key key = Keys.secretKeyFor(SignatureAlgorithm.HS256); // Генерация ключа
        return Jwts.builder()
                .setSubject(subject)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + ttlMillis))
                .signWith(key)
                .compact();
    }
}

Парсинг и валидация JWT

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

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.security.Keys;

public class JwtExample {
    public static Claims parseJwt(String jwt, String secret) {
        Key key = Keys.hmacShaKeyFor(secret.getBytes());
        return Jwts.parserBuilder()
                .setSigningKey(key)
                .build()
                .parseClaimsJws(jwt)
                .getBody();
    }
}

Управление памятью и производительность

1. Размер токена и влияние на память

JWT компактны, но их размер зависит от содержимого payload и используемого алгоритма.

Например:
HMAC-SHA256 (симметричный) создает токены меньшего размера, так как используется один ключ.
RSA/ECDSA (асимметричные алгоритмы) увеличивают размер подписи, что может быть заметно при большом количестве токенов.
Payload с большим количеством claims (например, сложные JSON-объекты) увеличивает объем токена, что влияет на объем передаваемых данных и потребление памяти.

Рекомендации:
Минимизируйте количество claims в payload. Храните только необходимые данные, такие как sub, iat, exp.
Используйте сжатие (например, JWS Compression с DEF в jjwt) для уменьшения размера токена, если это допустимо.


#Java #middle #on_request #Jwt

2. Кэширование ключей

Создание и парсинг ключей (особенно для асимметричных алгоритмов, таких как RSA) — дорогостоящая операция с точки зрения CPU и памяти.

Например:
Генерация RSA-ключей требует значительных вычислительных ресурсов.
Повторное декодирование Base64-строк для ключей при каждом запросе увеличивает нагрузку.

Рекомендации:
Кэшируйте ключи в памяти (например, в ConcurrentHashMap или с использованием Spring Cache).
Используйте пул ключей для многопоточных приложений, чтобы избежать создания новых экземпляров Key для каждого запроса.

Пример кэширования ключа:

private static final Key SIGNING_KEY = Keys.secretKeyFor(SignatureAlgorithm.HS256);

public static String createJwt(String subject, long ttlMillis) {
    return Jwts.builder()
            .setSubject(subject)
            .setIssuedAt(new Date())
            .setExpiration(new Date(System.currentTimeMillis() + ttlMillis))
            .signWith(SIGNING_KEY)
            .compact();
}

3. Многопоточность

Библиотека jjwt потокобезопасна, но неправильное управление ключами или токенами может привести к проблемам.

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

Рекомендации:
Создавайте и конфигурируйте JwtParserBuilder один раз и переиспользуйте его.
Используйте ThreadLocal только для временных данных, которые очищаются после обработки запроса.

Пример потокобезопасного парсера:

private static final JwtParser JWT_PARSER = Jwts.parserBuilder()
        .setSigningKey(Keys.hmacShaKeyFor("secret".getBytes()))
        .build();

public static Claims parseJwt(String jwt) {
    return JWT_PARSER.parseClaimsJws(jwt).getBody();
}

Нюансы безопасности

1. Выбор алгоритма подписи
HMAC-SHA (HS256, HS384, HS512): Быстрее, но требует безопасного хранения секретного ключа на всех серверах. Утечка ключа компрометирует всю систему.
RSA/ECDSA: Медленнее, но безопаснее, так как публичный ключ используется для проверки, а приватный хранится только на сервере, выдающем токены.
None-алгоритм: Никогда не используйте alg: none, так как это позволяет подделывать токены без подписи.

Рекомендации:
Для микросервисов с централизованным управлением ключами предпочтительнее RSA/ECDSA.

Используйте jjwt с настройкой require("alg"), чтобы предотвратить атаки с изменением алгоритма:

Jwts.parserBuilder()
    .require("alg", "RS256")
    .setSigningKey(publicKey)
    .build();

2. Срок действия токена
Короткий срок действия (exp) снижает риск использования украденных токенов, но увеличивает нагрузку на сервер из-за частого обновления токенов (refresh tokens).

Рекомендации:
Устанавливайте exp в пределах 15-60 минут для access-токенов.
Используйте refresh-токены с более длинным сроком действия и строгим контролем (например, храните их в базе данных с возможностью отзыва).

3. Уязвимости
JWT Header Injection: Атакующий может изменить заголовок, чтобы подменить алгоритм (например, с RS256 на HS256). Всегда проверяйте алгоритм при парсинге.
Weak Keys: Слабые или предсказуемые ключи для HMAC-SHA делают токены уязвимыми для brute-force атак.
Payload Tampering: Если токен не подписан или подпись не проверяется, злоумышленник может изменить payload.

Рекомендации:
Используйте ключи достаточной длины (например, 256 бит для HS256).
Проверяйте подпись токена на каждом запросе.
Включайте jti (JWT ID) для отслеживания и отзыва токенов.


#Java #middle #on_request #Jwt

Оптимизация и масштабирование

1. Хранение и ротация ключей
Для HMAC-SHA ключи должны безопасно храниться (например, в Vault или AWS KMS).
Для RSA/ECDSA используйте ротацию ключей с поддержкой JWK (JSON Web Key) для автоматического обновления публичных ключей.

2. Масштабирование в микросервисах
Централизуйте выдачу токенов через отдельный сервис (например, Auth Service).
Используйте JWK для распространения публичных ключей между сервисами.

3. Кэширование токенов
Кэшируйте проверенные токены в Redis или другом in-memory хранилище, чтобы снизить нагрузку на парсинг и валидацию.
Используйте TTL кэша, соответствующий exp токена.

4. Логирование и мониторинг
Логируйте попытки использования невалидных или истекших токенов для анализа атак.
Мониторьте время парсинга и валидации токенов, чтобы выявить узкие места.


Пример интеграции с Spring Security

JWT часто используется в связке с Spring Security для защиты REST API.

Пример конфигурации:

import io.jsonwebtoken.Jwts;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;

@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
            .antMatchers("/api/public").permitAll()
            .anyRequest().authenticated()
            .and()
            .addFilterBefore(new JwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);
        return http.build();
    }
}

public class JwtAuthenticationFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {
        String header = request.getHeader("Authorization");
        if (header != null && header.startsWith("Bearer ")) {
            String token = header.substring(7);
            try {
                Claims claims = Jwts.parserBuilder()
                        .setSigningKey(Keys.hmacShaKeyFor("secret".getBytes()))
                        .build()
                        .parseClaimsJws(token)
                        .getBody();
                String username = claims.getSubject();
                if (username != null) {
                    UsernamePasswordAuthenticationToken auth = new UsernamePasswordAuthenticationToken(
                            username, null, Collections.emptyList());
                    SecurityContextHolder.getContext().setAuthentication(auth);
                }
            } catch (Exception e) {
                SecurityContextHolder.clearContext();
            }
        }
        chain.doFilter(request, response);
    }
}

#Java #middle #on_request #Jwt

Модульность и многомодульные проекты в 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