Модульность и Gradle

1. Настройка многомодульного проекта в Gradle

Gradle использует декларативный подход для настройки проектов. В отличие от Maven, где конфигурация задается в XML, Gradle использует Groovy или Kotlin DSL, что делает его более гибким и мощным.

Структура многомодульного проекта:

parent-project/
├── build.gradle
├── settings.gradle
├── module1/
│   └── build.gradle
├── module2/
│   └── build.gradle
└── module3/
    └── build.gradle

settings.gradle — определяет, какие модули входят в проект.
build.gradle — корневой файл сборки, который может содержать общие настройки для всех модулей.

Пример settings.gradle:

rootProject.name = 'parent-project'
include 'module1', 'module2', 'module3'

Пример корневого build.gradle:

allprojects {
    group = 'com.example'
    version = '1.0-SNAPSHOT'
}

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

Пример build.gradle для модуля (module1):

dependencies {
    // Зависимости модуля
}

2. Управление зависимостями между модулями

В Gradle зависимости между модулями добавляются с помощью ключевого слова project.

Например, если module2 зависит от module1, то в build.gradle module2 нужно добавить:

dependencies {
    implementation project(':module1')
}

Плюсы:
Гибкость и мощь Groovy/Kotlin DSL.
Быстрая сборка благодаря инкрементальной компиляции.
Поддержка современных практик, таких как контейнеризация.

Минусы:
Более сложная настройка по сравнению с Maven.
Требует знания Groovy/Kotlin.

3. Пример конфигурации build.gradle для модульного проекта

Корневой build.gradle:

allprojects {
    group = 'com.example'
    version = '1.0-SNAPSHOT'
}

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

build.gradle для module1:

dependencies {
    // Зависимости модуля
}

build.gradle для module2:

dependencies {
    implementation project(':module1')
}

build.gradle для module3:

dependencies {
    implementation project(':module2')
}

Сборка и запуск модульных проектов

1. Сборка модульного проекта с помощью Gradle

Gradle:

gradle build

2. Запуск модульного приложения
Для запуска приложения, собранного с помощью Gradle, используйте команду java -jar, указав путь к JAR-файлу.

Пример:

java -jar module3/build/libs/module3-1.0-SNAPSHOT.jar

3. Использование jlink для создания минимальных runtime-образов

jlink — это утилита, которая позволяет создавать минимальные runtime-образы Java, включающие только необходимые модули. Это полезно для уменьшения размера приложения.

Пример использования:

jlink --module-path $JAVA_HOME/jmods:mods --add-modules com.example.module1 --output myapp-runtime

Плюсы:
Уменьшение размера приложения.
Ускорение запуска приложения.
Упрощение развертывания.

Минусы:
Требует знания модульной системы Java.
Необходимость тщательного планирования зависимостей.
Пример полного цикла: от сборки до запуска

Сборка проекта:

gradle build

Создание runtime-образа:

jlink --module-path $JAVA_HOME/jmods:mods --add-modules com.example.module1 --output myapp-runtime

Запуск приложения:

./myapp-runtime/bin/java -m com.example.module1/com.example.module1.Main

#Java #Training #Medium #JPMS #Gradle #Jlink

Введение в Gradle и концептуальная архитектура

Что такое Gradle? Эволюция от Ant и Maven

Gradle — это инструмент автоматизации сборки с открытым исходным кодом, предназначенный для управления проектами на Java, Kotlin, Scala, C++ и других языках. Он сочетает декларативный подход Maven с гибкостью Ant, используя Groovy или Kotlin для описания сборки. Gradle был создан в 2007 году Хансом Доктером и Адамом Мердоком и с тех пор стал стандартом для многих современных проектов, включая Android и Spring Boot.

Эволюция

Ant (2000): Первый широко используемый инструмент сборки для Java. Ant применяет императивный подход, где разработчик вручную описывает задачи в XML-файле (build.xml). Он не предоставляет встроенного управления зависимостями или жизненного цикла, что делает его гибким, но сложным для крупных проектов.

Maven (2004): Ввел декларативный подход с жизненным циклом (clean, build, site) и управлением зависимостями через репозитории. Maven использует XML (POM.xml), что обеспечивает стандартизацию, но ограничивает гибкость для нестандартных сценариев.

Gradle (2007): Объединяет преимущества Ant и Maven, предлагая:
Гибкость: Возможность писать программную логику для задач с помощью Groovy или Kotlin.
Производительность: Инкрементальная сборка и кэширование задач.
Декларативность: Простое описание зависимостей и плагинов, аналогичное Maven.
Многопроектная поддержка: Эффективное управление многомодульными проектами.

Gradle стал популярным благодаря поддержке Android Studio, высокой производительности и активному сообществу.
В памяти: Gradle работает как Java-приложение, загружая конфигурационные файлы (build.gradle, settings.gradle), плагины и зависимости в оперативную память. В отличие от Maven, Gradle использует Groovy/Kotlin для парсинга скриптов, что увеличивает потребление памяти из-за динамической природы этих языков, но оптимизируется за счет кэширования и инкрементальности.


Архитектура Gradle

Архитектура Gradle построена вокруг концепции задач (tasks) и графа выполнения, что отличает его от жизненного цикла Maven. Рассмотрим ключевые аспекты.


Task-based Model vs Lifecycle-based (в Maven)

Task-based Model (Gradle):
Gradle использует модель, основанную на задачах, где каждая задача (task) — это атомарная единица работы (например, компиляция, тестирование, упаковка).
Задачи определяются в build.gradle и могут быть связаны через зависимости (например, задача build зависит от compileJava).
Разработчик может создавать кастомные задачи с программной логикой, что обеспечивает гибкость.

Пример:

task hello {
    doLast {
        println 'Hello, Gradle!'
    }
}

Lifecycle-based Model (Maven):
Maven использует фиксированный жизненный цикл (clean, default, site) с фазами (compile, test, package), к которым привязаны плагины.
Ограниченная гибкость: задачи определяются через плагины, а не напрямую.

В памяти:
В Gradle каждая задача представлена как объект в памяти, содержащий конфигурацию и зависимости. Это увеличивает потребление памяти по сравнению с Maven, где фазы жизненного цикла имеют более жесткую структуру. Однако Gradle оптимизирует выполнение, пропуская неизмененные задачи (см. инкрементальность).


Directed Acyclic Graph (DAG) исполнения задач

Gradle строит Directed Acyclic Graph (DAG) для задач, где:
Узлы — это задачи.
Ребра — зависимости между задачами (например, build зависит от test, а test — от compileJava).

Gradle анализирует DAG, чтобы определить порядок выполнения задач и избежать циклов.

Процесс:
Gradle парсит build.gradle и создает объекты задач в памяти.
Формируется DAG на основе зависимостей, указанных в dependsOn или неявно через плагины.
Gradle выполняет задачи в порядке, определенном топологической сортировкой DAG, пропуская те, которые не требуются.

Пример:

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

#Java #middle #Gradle

Инкрементальность и кэширование

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

Пример:
Задача compileJava проверяет хэши исходных файлов и пропускает компиляцию, если они не изменились.

Кэширование:
Локальный кэш: Gradle хранит результаты задач в ~/.gradle/caches, что позволяет повторно использовать артефакты между сборками.
Build Cache: Gradle может кэшировать результаты задач на удаленном сервере (например, в CI/CD), что ускоряет сборку на разных машинах.

Настройка в settings.gradle:

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

В памяти:
Инкрементальность требует хранения хэшей входных/выходных данных в памяти для сравнения, что добавляет overhead. Build Cache минимизирует повторные вычисления, но требует дополнительной памяти для управления метаданными кэша.


Сравнение Gradle vs Maven

Гибкость, декларативность, производительность

Гибкость:
Gradle: Позволяет писать программную логику в задачах, используя Groovy/Kotlin. Подходит для нестандартных сценариев (например, кастомные процессы сборки).
Maven: Ограничивает кастомизацию плагинами и XML, что менее гибко для сложных задач.

Декларативность:
Maven: Полностью декларативный подход через XML (POM.xml), что упрощает стандартизацию, но ограничивает выразительность.
Gradle: Сочетает декларативность (зависимости, плагины) с императивной логикой, что делает его более выразительным.

Производительность:
Gradle: Быстрее за счет инкрементальной сборки, кэширования и параллельного выполнения задач. Флаг --parallel ускоряет многомодульные проекты.
Maven: Медленнее из-за последовательного выполнения фаз и отсутствия встроенной инкрементальности. Флаг -T частично компенсирует это.

В памяти:
Gradle потребляет больше памяти из-за динамической природы Groovy/Kotlin и сложных DAG. Maven экономичнее, так как использует фиксированную структуру жизненного цикла, но менее эффективен по времени выполнения.


Groovy DSL vs XML (Maven)

Groovy DSL (Gradle):
Использует Groovy для описания сборки, что делает синтаксис компактным и выразительным.

Пример:

plugins {
    id 'java'
}
dependencies {
    implementation 'org.springframework:spring-core:5.3.20'
}


Преимущества: Легко читаемый код, поддержка программной логики, динамическая конфигурация.
Недостатки: Требует изучения Groovy, потенциальные ошибки из-за динамической типизации.

XML (Maven):
Использует XML (POM.xml), что делает конфигурацию строгой и стандартизированной.

Пример:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>5.3.20</version>
</dependency>

Преимущества: Простота для новичков, строгая структура, поддержка инструментами (IDE).
Недостатки: Многословность, ограниченная гибкость.

В памяти:
Парсинг Groovy DSL в Gradle требует загрузки Groovy-библиотек и динамической компиляции скриптов, что увеличивает потребление памяти по сравнению с XML-парсингом Maven, который использует более легковесные парсеры (например, StAX).

#Java #middle #Gradle

Поддержка Groovy DSL и Kotlin DSL

Gradle поддерживает два языка для написания скриптов сборки:

Groovy DSL:
Основной язык Gradle, используемый в build.gradle.
Динамическая типизация, лаконичный синтаксис.

Пример:

plugins {
    id 'java'
}
repositories {
    mavenCentral()
}

Kotlin DSL:
Введен для статической типизации и лучшей поддержки в IDE.
Используется в build.gradle.kts.

Пример:

plugins {
    java
}
repositories {
    mavenCentral()
}

Преимущества: Статическая типизация, автодополнение в IDE, меньше ошибок на этапе выполнения.
Недостатки: Более строгий синтаксис, требует изучения Kotlin.

Выбор:
Используйте Groovy для простоты и совместимости с существующими проектами.
Выберите Kotlin для новых проектов, особенно если команда знакома с Kotlin или требуется строгая типизация.


Build Scans — что это и зачем

Build Scans — это инструмент Gradle для анализа и отладки сборок.

Они представляют собой веб-отчеты, содержащие:
Детали выполнения задач (время, зависимости, пропущенные задачи).
Информацию о конфигурации (плагины, зависимости, свойства).
Логи ошибок и предупреждений.

Настройка:

Добавьте плагин в build.gradle:
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 в консоли.

Зачем:
Отладка: Выявление узких мест (например, медленных задач).
Оптимизация: Анализ пропущенных задач и кэширования.
Совместная работа: Делитесь Build Scans с командой для диагностики проблем.
CI/CD: Интеграция с Gradle Enterprise для хранения и анализа сборок.

В памяти: Build Scan собирает метаданные о сборке в памяти, включая DAG, время выполнения задач и конфигурацию. Это увеличивает потребление памяти, особенно для крупных проектов. Данные отправляются на сервер Gradle Enterprise, что требует сетевых операций.


#Java #middle #Gradle

Конфигурационные файлы: build.gradle, settings.gradle, gradle.properties

Gradle использует три основных файла конфигурации:

build.gradle:

Основной файл сборки, определяющий задачи, плагины и зависимости.

Пример:

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.18'
}
repositories {
    mavenCentral()
}
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    testImplementation 'junit:junit:4.13.2'
}

В памяти: Парсится в объектную модель Gradle, включая задачи и зависимости. Динамическая компиляция Groovy/Kotlin увеличивает overhead.

settings.gradle:

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

Пример:

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

В памяти: Формирует модель проекта, включая граф модулей. Меньше по объему, чем build.gradle, но влияет на DAG.

gradle.properties:

Хранит свойства для настройки Gradle и JVM.

Пример:

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

В памяти: Свойства загружаются как часть конфигурации Gradle, минимально влияя на память.

Нюансы:
Храните build.gradle и settings.gradle в корне проекта, а gradle.properties — в корне или ~/.gradle.
Используйте gradle.properties для чувствительных данных (например, ключи API) с осторожностью, предпочтительно шифруйте их.
В многомодульных проектах каждый модуль имеет свой build.gradle, но общий settings.gradle.


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

Управление памятью:
Gradle загружает модель проекта, задачи и зависимости в JVM. Groovy/Kotlin DSL увеличивают overhead из-за динамической компиляции.
Инкрементальность и кэширование снижают повторные вычисления, но требуют памяти для хранения хэшей и метаданных.
Настройте org.gradle.jvmargs в gradle.properties для увеличения кучи: -Xmx2048m.

Кэширование:
Локальный кэш (~/.gradle/caches) хранит зависимости, плагины и результаты задач.
Build Cache (локальный или удаленный) минимизирует повторные сборки, но требует настройки и дискового пространства.
Очистка кэша: ./gradlew --stop и rm -rf ~/.gradle/caches.

Производительность:
Инкрементальная сборка и --parallel ускоряют выполнение, но увеличивают пиковое потребление памяти.
Используйте --no-daemon для одноразовых сборок, чтобы избежать постоянного процесса Gradle Daemon.

Отладка:
Флаг --info или --debug выводит подробные логи:./gradlew build --debug
Build Scans предоставляют визуальный анализ.
Используйте ./gradlew tasks для списка доступных задач.


Многомодульные проекты:
Gradle эффективно управляет модулями через settings.gradle, строя DAG для определения порядка сборки.
Используйте ./gradlew :module-name:task для выполнения задачи в конкретном модуле.

Совместимость:
Gradle требует JDK 8+ (рекомендуется 11+). Убедитесь, что JAVA_HOME указывает на правильный JDK.
Некоторые плагины Maven (например, maven-release-plugin) требуют адаптации для Gradle (например, nebula-release-plugin).

#Java #middle #Gradle

Структура build-файла Gradle

Файл build.gradle (или build.gradle.kts) является основным конфигурационным файлом Gradle, определяющим, как собирать проект. Он состоит из ключевых блоков, которые задают плагины, репозитории, зависимости, задачи и конфигурации.

Основные элементы

Plugins:
Блок plugins определяет плагины, которые добавляют задачи, настройки и функциональность.

Пример (Groovy DSL):

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

Пример (Kotlin DSL):

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

Плагины могут быть:
Core plugins (например, java, application): встроены в Gradle.
Community plugins: загружаются из репозиториев (например, Maven Central).

В памяти: Плагины загружаются как Java-классы в JVM, увеличивая потребление памяти пропорционально их зависимостям и сложности.

Repositories:
Указывают, откуда Gradle загружает зависимости и плагины (например, Maven Central, JCenter).

Пример:

repositories {
    mavenCentral()
    maven { url 'https://repo.example.com' }
}

В памяти: Gradle загружает метаданные репозиториев (POM-файлы, индексы) в память для разрешения зависимостей, что требует временного увеличения ресурсов.

Dependencies:
Определяют библиотеки и модули, необходимые проекту.

Пример:

dependencies {
    implementation 'org.springframework:spring-core:5.3.20'
    testImplementation 'junit:junit:4.13.2'
}

Конфигурации (например, implementation, testImplementation) определяют область видимости зависимостей (аналогично scope в Maven).

В памяти: Gradle строит граф зависимостей (Directed Acyclic Graph, DAG), хранящий метаданные каждой зависимости. Это увеличивает потребление памяти, особенно для крупных проектов.

Tasks:
Задачи — это атомарные единицы работы (например, компиляция, тестирование).

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

task hello {
    doLast {
        println 'Hello, Gradle!'
    }
}

Задачи могут зависеть друг от друга через dependsOn:task build(dependsOn:

['test', 'jar']) {
    doLast { println 'Building project' }
}

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

Configurations:
Конфигурации определяют группы зависимостей для разных целей (например, implementation для компиляции, testImplementation для тестов).

Пример:

configurations {
    customConfig
}
dependencies {
    customConfig 'com.example:library:1.0'
}

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

Пример полного build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.18'
}
repositories {
    mavenCentral()
}
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    testImplementation 'junit:junit:4.13.2'
}
tasks.register('customTask') {
    doLast {
        println 'Custom task executed'
    }
}

В памяти: Файл build.gradle парсится в объектную модель, включающую плагины, зависимости и задачи. Groovy DSL требует загрузки Groovy-библиотек, а Kotlin DSL — Kotlin-библиотек, что увеличивает потребление памяти.

#Java #middle #Gradle #Build_gradle

Скриптовый движок (Groovy/Kotlin)

Gradle использует два языка для описания сборки:

Groovy DSL:
Основан на Groovy, динамически типизированном языке.
Преимущества: Простота, лаконичный синтаксис, широкая совместимость.
Недостатки: Ошибки могут обнаруживаться только на этапе выполнения из-за динамической типизации.

Пример:

dependencies {
    implementation 'org.springframework:spring-core:5.3.20'
}

Kotlin DSL:
Основан на Kotlin, статически типизированном языке.
Преимущества: Автодополнение в IDE, раннее обнаружение ошибок, лучшая интеграция с Kotlin-проектами.
Недостатки: Более строгий синтаксис, требует знания Kotlin.

Пример:

dependencies {
    implementation("org.springframework:spring-core:5.3.20")
}

В памяти: Groovy DSL компилируется динамически, загружая Groovy-библиотеки (например, groovy-all) в JVM, что увеличивает потребление памяти (около 50-100 МБ дополнительно). Kotlin DSL требует загрузки Kotlin-библиотек (kotlin-stdlib, kotlin-scripting), что добавляет аналогичный overhead, но статическая типизация снижает вероятность ошибок. Gradle кэширует результаты парсинга в ~/.gradle/caches для ускорения повторных сборок.

Gradle Project Object Model

Gradle Project Object Model (POM, не путать с Maven POM) — это внутренняя модель, представляющая проект в памяти.

Она включает:
Project: Корневой объект, содержащий свойства (group, name, version), задачи, зависимости и плагины.
Tasks: Объекты задач, связанные через DAG.
Dependencies: Граф зависимостей, организованный по конфигурациям.
Properties: Свойства проекта, доступные через ${project.property}.
Subprojects: Для многомодульных проектов, каждый подпроект имеет свою модель.

Пример доступа:

println project.name
println project.version

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

Gradle Lifecycle Overview: Initialization → Configuration → Execution

Gradle выполняет сборку в три фазы:

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

В памяти: Загружаются settings.gradle и плагины, необходимые для инициализации. Это минимальная фаза по потреблению памяти.

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

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

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

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

Нюансы:
Конфигурация выполняется всегда, даже если задачи не запускаются, что увеличивает время инициализации.
Используйте флаг --configure-on-demand для конфигурации только необходимых модулей:./gradlew build --configure-on-demand
Gradle Daemon сохраняет JVM между сборками, ускоряя повторные запуски, но увеличивая базовое потребление памяти.


#Java #middle #Gradle #Build_gradle

Gradle Properties

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

Project-level:
Определяются в build.gradle или settings.gradle.

Пример:

version = '1.0.0'
ext.myProperty = 'value'

Доступ:

project.version, project.myProperty.

System-level:
Задаются через командную строку (-D) или gradle.properties.
Пример (gradle.properties):org.gradle.jvmargs=-Xmx2048m

Доступ:
System.getProperty('org.gradle.jvmargs').

Environment-level:
Переменные окружения, доступные через System.getenv().
Пример:println System.getenv('JAVA_HOME')

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

В памяти: Свойства загружаются как часть модели проекта или JVM, требуя минимальных ресурсов. Однако большое количество свойств в gradle.properties увеличивает время парсинга.

Различия Groovy DSL и Kotlin DSL
Groovy DSL
Kotlin DSL


Файл
build.gradle
build.gradle.kts

Типизация
Динамическая
Статическая

Синтаксис
Лаконичный, гибкий
Более строгий, с явными типами

IDE-поддержка
Хорошая, но ограниченное автодополнение
Отличная, с сильным автодополнением

Пример зависимости

implementation 'org.example:lib:1.0'
implementation("org.example:lib:1.0")

Ошибки
Обнаруживаются на этапе выполнения
Обнаруживаются на этапе компиляции

Производительность
Быстрее парсинг, но больше памяти на Groovy
Медленнее парсинг, но меньше ошибок

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

Рекомендации:
Используйте Groovy для простых проектов или совместимости с существующими скриптами.
Выберите Kotlin для новых проектов, особенно если команда использует Kotlin или требуется строгая типизация.


#Java #middle #Gradle #Build_gradle

Распределение конфигурации: build.gradle, settings.gradle, gradle.properties

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

В памяти: Парсится в модель проекта, включая DAG задач и граф зависимостей.

settings.gradle:
Определяет структуру проекта: корневое имя, подмодули, настройки кэширования.

Пример:

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

Роль: Управляет инициализацией многомодульного проекта.

В памяти: Загружается первым, формируя модель проекта и граф модулей. Меньше по объему, чем build.gradle.

gradle.properties:
Хранит свойства для настройки Gradle, JVM и проекта.
Пример:

org.gradle.parallel=true
myVersion=1.0.0

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

В памяти: Загружается как часть конфигурации Gradle, минимально влияя на память.

Распределение конфигурации:
Общие настройки: Храните в gradle.properties (например, JVM-аргументы, версии).
Структура проекта: Определяйте в settings.gradle (модули, кэш).
Логика сборки: Описывайте в build.gradle (задачи, зависимости).

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

allprojects {
    repositories {
        mavenCentral()
    }
}

Храните чувствительные данные (например, ключи API) в ~/.gradle/gradle.properties с ограниченными правами доступа.

В памяти: Конфигурационные файлы загружаются последовательно: gradle.properties → settings.gradle → build.gradle. Gradle кэширует результаты парсинга в ~/.gradle/caches, снижая overhead при повторных сборках.
Нюансы и внутренние механизмы

Управление памятью:
Gradle загружает модель проекта, задачи и зависимости в JVM. Для крупных проектов с сотнями задач и зависимостей потребление памяти может достигать 1-2 ГБ.
Groovy/Kotlin DSL увеличивают overhead из-за динамической/статической компиляции.
Gradle Daemon сохраняет JVM между сборками, ускоряя выполнение, но увеличивая базовое потребление памяти (около 200-300 МБ).
Оптимизируйте с помощью org.gradle.jvmargs=-Xmx2048m и --no-daemon для одноразовых сборок.

Кэширование:
Локальный кэш (~/.gradle/caches) хранит зависимости, плагины и результаты задач, снижая сетевые запросы.
Build Cache (локальный или удаленный) минимизирует повторные вычисления, но требует настройки и дискового пространства.
Очистка кэша: ./gradlew --stop и rm -rf ~/.gradle/caches.

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

Отладка:
Флаг --info или --debug выводит подробные логи:./gradlew build --debug
Используйте ./gradlew tasks для списка задач или ./gradlew dependencies для анализа зависимостей.
Build Scans предоставляют визуальный анализ сборки.

Многомодульные проекты:
Gradle эффективно управляет модулями через settings.gradle, строя DAG для определения порядка сборки.
Выполняйте задачи для конкретного модуля: ./gradlew :module-name:build.

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


#Java #middle #Gradle #Build_gradle