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

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

Введение в Nginx

Nginx (произносится как "engine x") — это высокопроизводительное программное обеспечение с открытым исходным кодом, выполняющее функции веб-сервера, обратного прокси-сервера, балансировщика нагрузки, TCP/UDP-прокси и почтового прокси-сервера. Созданное Игорем Сысоевым в 2004 году, оно распространяется под лицензией BSD из 2 пунктов. Nginx завоевал популярность благодаря своей скорости, стабильности и низкому потреблению ресурсов, что делает его выбором для многих высоконагруженных сайтов, таких как Netflix, Dropbox, Яндекс и ВКонтакте.

Согласно данным W3Techs (по состоянию на апрель 2025 года), Nginx занимает первое место среди веб-серверов, обслуживая 33,8% всех веб-сайтов, опережая Apache (26,4%) и Cloudflare Server (23,4%). Это подчеркивает его широкое признание и надежность.


Как работает Nginx?

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

Основные аспекты его работы включают:
Один основной процесс и несколько рабочих процессов: Основной процесс управляет конфигурацией и координирует работу, а рабочие процессы обрабатывают запросы пользователей. Это снижает накладные расходы по сравнению с многопоточной моделью, используемой, например, в Apache.
Механизмы событий: Nginx поддерживает такие технологии, как kqueue (FreeBSD), epoll (Linux) и другие, для эффективной обработки сетевых соединений.
Оптимизация передачи данных: Использование технологий, таких как sendfile и асинхронный ввод/вывод (AIO), минимизирует копирование данных и ускоряет доставку контента.
Низкое потребление памяти: Например, для 10 000 неактивных HTTP keep-alive соединений требуется всего около 2,5 МБ памяти.

Запросы пользователей разбиваются на небольшие сетевые соединения, которые обрабатываются асинхронно. После обработки они собираются в единый ответ и отправляются клиенту. Одно соединение может обрабатывать до 1024 запросов, что значительно повышает производительность.


Для чего нужен Nginx?

Nginx универсален и применяется в различных сценариях:
Веб-сервер
Обслуживает статический контент (HTML, CSS, изображения, JavaScript) с высокой скоростью.

Обратный прокси
Перенаправляет запросы к другим серверам, скрывая их от клиента.

Балансировка нагрузки
Распределяет входящий трафик между несколькими серверами для повышения отказоустойчивости.

Кеширование
Сохраняет часто запрашиваемый контент для ускорения доставки.

Почтовый прокси
Поддерживает протоколы IMAP, POP3, SMTP с возможностью аутентификации через HTTP.

Безопасность
Поддерживает SSL/TLS, ограничение доступа по IP и защиту от DDoS-атак.

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


Почему выбрать Nginx?

Nginx выделяется среди других веб-серверов, таких как Apache, по нескольким причинам:
Высокая производительность: Асинхронная архитектура позволяет обрабатывать больше запросов с меньшими ресурсами.
Эффективность для статического контента: Nginx быстрее Apache в доставке статических файлов, таких как изображения и CSS.
Модульная архитектура: Легко расширяется с помощью модулей для добавления новых функций.
Низкое потребление ресурсов: Минимизирует использование памяти и процессора, что идеально для серверов с ограниченными ресурсами.
Широкое применение: Используется крупными компаниями, такими как Netflix, Dropbox и WordPress.com, что подтверждает его надежность.

Nginx также может работать в связке с Apache: Nginx обрабатывает статический контент, а Apache — динамический, что оптимизирует производительность сайта.


#Java #middle #on_request #nginx