Жизненный цикл в многомодульных проектах

Жизненный цикл в многомодульных проектах аналогичен одномодульному, но применяется к каждому модулю индивидуально. Основные фазы (Clean, Default, Site) выполняются в порядке, определенном реактором.

Последовательность: Реактор вызывает фазы жизненного цикла (например, validate, compile, package) для каждого модуля по очереди. Например, mvn package сначала выполнит package для module-api, затем для module-core и так далее.
Параллельность: С флагом -T Maven выполняет фазы для независимых модулей параллельно, что ускоряет сборку, но увеличивает потребление памяти из-за одновременной загрузки нескольких POM-моделей и плагинов.
Общие ресурсы: Родительский POM задает общие плагины и зависимости, которые загружаются в память один раз и используются всеми модулями, оптимизируя ресурсы.
Пропуск фаз: Флаги, такие как -DskipTests, применяются ко всем модулям, что снижает нагрузку на память.

В памяти Maven хранит модель жизненного цикла для каждого модуля, включая привязки плагинов к фазам. Для крупных проектов это может привести к значительному потреблению памяти, особенно на фазах, таких как compile или test, где загружаются исходные файлы, зависимости и результаты тестов.

Нюансы

Инкрементальная сборка: Maven использует временные метки файлов в target, чтобы пропускать неизмененные модули. Это снижает нагрузку на память и процессор.
Ошибки в модуле: Если одна фаза завершается с ошибкой в модуле, Maven останавливает сборку, но уже созданные артефакты сохраняются.
Кэширование артефактов: Модули, установленные в ~/.m2/repository (через mvn install), не пересобираются при повторных запусках, что оптимизирует производительность.


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

Управление памятью:
Maven загружает модель POM для каждого модуля, создавая объединенную модель проекта. Это увеличивает потребление памяти пропорционально количеству модулей.
Реактор строит граф модулей в памяти, что требует дополнительных ресурсов для хранения и сортировки.
Параллельная сборка (-T) увеличивает пиковое потребление памяти из-за одновременной обработки нескольких модулей.
Для оптимизации используйте -pl для выборочной сборки и настройте JVM с помощью -Xmx.

Кэширование:
Локальный репозиторий (~/.m2/repository) кэширует артефакты модулей, что снижает необходимость повторной сборки.
Maven использует файлы _remote.repositories для отслеживания происхождения артефактов, минимизируя сетевые запросы.

Конфликты зависимостей:
Модули могут использовать разные версии одной библиотеки, что приводит к конфликтам. Используйте <dependencyManagement> для согласованности.
Плагин maven-enforcer-plugin с правилом dependencyConvergence помогает выявить конфликты.

Производительность:
Инкрементальная сборка и кэширование ускоряют процесс, но первый запуск или полная сборка (mvn clean) могут быть медленными.
Параллельная сборка сокращает время, но требует мощного оборудования из-за высокой нагрузки на память и процессор.

Отладка:
Используйте mvn -X для вывода подробной информации о порядке сборки и загрузке модулей.
Команда mvn dependency:tree -pl module-name помогает анализировать зависимости конкретного модуля.
Плагин help:effective-pom показывает итоговую конфигурацию модуля с учетом наследования.

CI/CD интеграция:
Настройте CI/CD для выполнения mvn clean install на каждое изменение, чтобы гарантировать целостность всех модулей.
Используйте матричные сборки для тестирования модулей в разных окружениях (например, разные версии Java).
Храните SNAPSHOT-версии в репозитории (например, Nexus) для промежуточных сборок, а релизные версии — в отдельном репозитории.

#Java #middle #Maven #Profiles #Parent_POM #MultiModule #Module_Inheritance

Расширенные темы и интеграции Maven

CI/CD интеграция

Maven широко используется в CI/CD-пайплайнах для автоматизации сборки, тестирования и развертывания. Рассмотрим интеграцию с популярными системами и связанные процессы, такие как GPG-подпись и развертывание артефактов.

Jenkins, GitLab CI, GitHub Actions с Maven

Jenkins:

Конфигурация: Создайте задачу (Job) типа "Freestyle" или "Pipeline". В Freestyle добавьте шаг "Invoke top-level Maven targets":mvn clean install

В Pipeline используйте Jenkinsfile:

pipeline {
    agent any
    tools {
        maven 'Maven 3.8.6'
        jdk 'JDK11'
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
    }
}

Параллельность: Используйте флаг -T для параллельной сборки модулей, например, -T 4.
Плагины: Используйте maven-release-plugin для автоматизации релизов:mvn release:prepare release:perform

GitLab CI:

Конфигурация: Определите .gitlab-ci.yml:

stages:
  - build
build:
  stage: build
  image: maven:3.8.6-openjdk-11
  script:
    - mvn clean install
  artifacts:
    paths:
      - target/*.jar

Кэширование: Кэшируйте ~/.m2/repository для ускорения:

cache:
  paths:
    - ~/.m2/repository

GitHub Actions:

Конфигурация: Создайте .github/workflows/maven.yml:name:

Maven Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
      - name: Build with Maven
        run: mvn clean install
      - name: Cache Maven dependencies
        uses: actions/cache@v3
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}

Артефакты: Используйте действие actions/upload-artifact для сохранения JAR/WAR.

В памяти: CI/CD-системы запускают Maven как Java-процесс, загружая POM-модель, зависимости и плагины в оперативную память. Параллельная сборка (-T) увеличивает пиковое потребление памяти, так как одновременно обрабатываются несколько модулей. Кэширование ~/.m2/repository снижает сетевые запросы, но требует места на диске.


Работа с GPG Signing, Artifact Deployment

GPG Signing:GPG-подпись артефактов необходима для публикации в Maven Central. Используется maven-gpg-plugin.

Настройка в POM.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>3.0.1</version>
    <executions>
        <execution>
            <id>sign-artifacts</id>
            <phase>verify</phase>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Шаги:
Установите GPG и создайте ключ: gpg --gen-key.
Опубликуйте публичный ключ: gpg --keyserver keyserver.ubuntu.com --send-keys <key-id>.

Настройте ~/.m2/settings.xml с GPG-паролем:

<server>
    <id>gpg.passphrase</id>
    <passphrase>{encrypted-passphrase}</passphrase>
</server>

Подпишите артефакты:

mvn clean deploy -Dgpg.passphrase=<passphrase>.

В памяти: Плагин maven-gpg-plugin загружает GPG-ключи и артефакты в память для подписи, что увеличивает потребление ресурсов, особенно для крупных JAR/WAR.

Artifact Deployment:Развертывание артефактов в репозиторий (например, Nexus, Maven Central) выполняется через maven-deploy-plugin:

<distributionManagement>
    <repository>
        <id>nexus</id>
        <url>https://nexus.example.com/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
        <id>nexus</id>
        <url>https://nexus.example.com/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Запуск: mvn deploy.
SNAPSHOT vs Release: SNAPSHOT-версии (1.0.0-SNAPSHOT) обновляются в репозитории, релизные версии (1.0.0) публикуются однократно.
В памяти: Плагин maven-deploy-plugin загружает артефакт и его метаданные в память перед отправкой в репозиторий. Сетевые операции могут замедлить процесс, но потребление памяти минимально.

#Java #middle #Maven #Best_practics

Archetypes

Архетипы — это шаблоны проектов, которые позволяют быстро создавать структуру с предопределенными файлами, зависимостями и конфигурацией. Maven предоставляет встроенные архетипы, такие как maven-archetype-quickstart.

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

mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4

Пользователь вводит groupId, artifactId, version, и Maven генерирует проект.

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

Создайте проект с желаемой структурой:

my-archetype/
├── src/
│   └── main/
│       └── resources/
│           ├── archetype-resources/
│           │   ├── src/main/java/App.java
│           │   └── pom.xml
│           └── META-INF/maven/
│               └── archetype-metadata.xml
└── pom.xml

В archetype-metadata.xml опишите структуру:

<archetype-descriptor>
    <fileSets>
        <fileSet filtered="true" packaged="true">
            <directory>src/main/java</directory>
            <includes>
                <include>**/*.java</include>
            </includes>
        </fileSet>
    </fileSets>
</archetype-descriptor>

Сгенерируйте архетип:

mvn archetype:create-from-project

Результат появится в target/generated-sources/archetype.

Установите архетип:

cd target/generated-sources/archetype
mvn install

Используйте архетип:

mvn archetype:generate -DarchetypeGroupId=com.example -DarchetypeArtifactId=my-archetype -DarchetypeVersion=1.0

В памяти: Архетипы загружают шаблонные файлы и их метаданные в память. Плагин maven-archetype-plugin парсит archetype-metadata.xml и заменяет переменные (например, ${groupId}), что требует минимальных ресурсов, но может быть затратным для сложных архетипов с большим количеством файлов.


Использование Maven Wrapper (mvnw)

Maven Wrapper (mvnw) — это скрипт, который обеспечивает использование конкретной версии Maven, независимо от установленной на машине. Он включает файлы mvnw (или mvnw.cmd для Windows), .mvn/wrapper/maven-wrapper.jar и .mvn/wrapper/maven-wrapper.properties.

Установка:

mvn -N wrapper:wrapper -Dmaven=3.8.6

Создает mvnw, который загружает указанную версию Maven.

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

./mvnw clean install

Скрипт проверяет .mvn/wrapper/maven-wrapper.properties, загружает нужную версию Maven и выполняет команду.

В памяти: mvnw запускает Maven как отдельный Java-процесс, загружая maven-wrapper.jar в память. Это добавляет небольшой overhead, но гарантирует согласованность сборки. Кэширование Maven в .m2/repository минимизирует сетевые запросы.

Нюансы:
Храните mvnw и .mvn в репозитории для обеспечения воспроизводимости.
Обновляйте версию Maven в maven-wrapper.properties для поддержки новых функций.


Поддержка Java версий

Maven поддерживает проекты с разными версиями Java через maven-compiler-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.10.1</version>
    <configuration>
        <source>11</source>
        <target>11</target>
    </configuration>
</plugin>

Многомодульные проекты

Каждый модуль может использовать разные версии Java, указав собственную конфигурацию плагина.

Toolchains: Для кросс-компиляции используйте ~/.m2/toolchains.xml:

<toolchains>
    <toolchain>
        <type>jdk</type>
        <provides>
            <version>11</version>
        </provides>
        <configuration>
            <jdkHome>/path/to/jdk11</jdkHome>
        </configuration>
    </toolchain>
</toolchains>

Укажите toolchain в POM.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-toolchains-plugin</artifactId>
    <version>3.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>toolchain</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <toolchains>
            <jdk>
                <version>11</version>
            </jdk>
        </toolchains>
    </configuration>
</plugin>

#Java #middle #Maven #Best_practics

Расширение Maven

Extensions

Расширения Maven — это JAR-файлы, которые добавляют функциональность, например, кастомные жизненные циклы или обработчики репозиториев.

Они указываются в .mvn/extensions.xml:

<extensions>
    <extension>
        <groupId>com.example</groupId>
        <artifactId>custom-extension</artifactId>
        <version>1.0</version>
    </extension>
</extensions>

Создание:
Создайте проект с зависимостью maven-core.
Реализуйте интерфейс, например, org.apache.maven.AbstractMavenLifecycleParticipant.
Упакуйте как JAR и установите в репозиторий.

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


Интернальные API Maven

Maven предоставляет API (maven-core, maven-plugin-api) для создания плагинов и расширений.

Пример использования org.apache.maven.project.MavenProject для доступа к модели проекта:

@Mojo(name = "custom")
public class CustomMojo extends AbstractMojo {
    @Parameter(defaultValue = "${project}")
    private MavenProject project;

    public void execute() throws MojoExecutionException {
        getLog().info("Project artifact: " + project.getArtifactId());
    }
}

В памяти: Интернальные API загружают объекты POM-модели и контекста сборки, что может быть ресурсоемким для сложных операций, таких как анализ зависимостей.

Логирование и отладка:

 -X, -e

Флаг -X: Включает отладочный режим, выводя подробную информацию о сборке, плагинах, зависимостях и реакторе:

mvn package -X

Увеличивает объем логов, что может замедлить выполнение и потребовать больше памяти для буферизации вывода.

Флаг -e: Выводит стек вызовов при ошибках:

mvn package -e

Полезно для диагностики, минимально влияет на память.

Плагины для отладки:
mvn help:effective-pom: Показывает итоговую модель POM.
mvn dependency:tree: Анализирует зависимости.
mvn help:effective-settings: Показывает настройки settings.xml.

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


Сравнение и миграция с Ant/Gradle

Ant

Сравнение:
Ant: Императивный подход, где задачи определяются вручную в XML (build.xml). Нет встроенного управления зависимостями или жизненного цикла.
Maven: Декларативный подход с жизненным циклом и автоматическим разрешением зависимостей.

Миграция:
Перенесите задачи Ant в плагины Maven (например, maven-antrun-plugin для запуска Ant-скриптов).
Преобразуйте зависимости в POM.xml с помощью <dependency>.
Используйте mvn ant:ant для генерации build.xml из Maven для обратной совместимости.


Gradle

Сравнение:
Gradle: Гибридный подход (декларативный + императивный), использует Groovy/Kotlin DSL. Более гибкий, но сложнее в освоении.
Maven: Стандартизированный XML, проще для новичков, но менее гибкий.
Gradle быстрее благодаря инкрементальной сборке и кэшированию.

Миграция:
Используйте build.gradle с плагином maven-publish для публикации артефактов в Maven-репозитории.
Конвертируйте POM.xml в build.gradle с помощью инструментов, таких как gradle init.
Перенесите зависимости из <dependencyManagement> в dependencies Gradle.

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

#Java #middle #Maven #Best_practics

Maven Best Practices: от Apache и Spring

Apache Best Practices
Централизация конфигурации: Используйте <dependencyManagement> и <pluginManagement> в родительском POM.
Минимизация зависимостей: Исключайте ненужные транзитивные зависимости через <exclusions>.
Профили: Используйте профили для окружений (dev, prod).
Кэширование: Настройте CI/CD для кэширования ~/.m2/repository.
Плагины: Используйте последние версии плагинов и проверяйте их совместимость.

Spring Best Practices

Spring Boot BOM: Используйте spring-boot-starter-parent или spring-boot-dependencies для управления версиями:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
</parent>

Минимизация конфигурации: Полагайтесь на автоконфигурацию Spring Boot вместо ручной настройки плагинов.

Плагины: Используйте spring-boot-maven-plugin для создания исполняемых JAR:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

В памяти: Spring Boot BOM увеличивает объем POM-модели из-за большого числа зависимостей, но упрощает управление версиями. Плагин spring-boot-maven-plugin загружает дополнительные данные для создания "fat JAR", что может быть ресурсоемким.


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

Управление памятью:
Maven загружает POM-модели, настройки и зависимости в память, создавая графы для модулей и артефактов. Крупные проекты с сотнями зависимостей могут потреблять гигабайты памяти.
Параллельная сборка (-T) и отладка (-X) увеличивают пиковое потребление.
Оптимизируйте с помощью -pl, -am и JVM-флагов (-Xmx).

Кэширование:
Локальный репозиторий (~/.m2/repository) снижает сетевые запросы, но требует периодической очистки устаревших SNAPSHOT-версий.
CI/CD-кэширование ускоряет сборку, но увеличивает использование диска.

Безопасность:
Шифруйте пароли для репозиториев с помощью mvn --encrypt-password.
Ограничивайте доступ к ~/.m2/settings-security.xml (chmod 600).


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

Отладка:
Используйте -X для анализа реактора и зависимостей.
Проверяйте конфликты с mvn dependency:tree -Dverbose.
Анализируйте итоговую конфигурацию с mvn help:effective-pom.


#Java #middle #Maven #Best_practics

Maven в IntelliJ IDEA: Встроенный Maven и его роль


Как работает встроенный Maven

Расположение: IntelliJ IDEA включает Maven в свою установку (обычно в <IntelliJ IDEA installation>/plugins/maven/lib).
Версия: IDEA использует конкретную версию Maven (например, 3.8.6 в последних версиях), которая обновляется с новыми релизами IDE.
Интеграция: IDEA вызывает Maven через внутренний API, а не через командную строку. Это позволяет управлять сборкой, зависимостями и плагинами из интерфейса IDE.

Конфигурация: Настройки хранятся в File > Settings > Build, Execution, Deployment > Build Tools > Maven:

Maven home path: По умолчанию Bundled (Maven).
User settings file: Можно указать ~/.m2/settings.xml.
Local repository: По умолчанию ~/.m2/repository, но можно настроить.

В памяти: Встроенный Maven загружается в JVM IntelliJ IDEA, разделяя память с IDE. Это увеличивает общее потребление памяти, особенно при выполнении сложных сборок. IDEA кэширует зависимости в ~/.m2/repository, синхронизируя их с системным Maven.


Замена системного Maven

IntelliJ IDEA по умолчанию использует встроенный Maven, но позволяет переключиться на системный:

Переключение на системный Maven:
Откройте File > Settings > Build, Execution, Deployment > Build Tools > Maven.
В поле Maven home path выберите путь к системной установке (например, C:\Program Files\Apache\maven-3.8.6 или /opt/apache-maven-3.8.6).
Перезапустите проект для применения изменений.


Почему встроенный Maven заменяет системный:
Удобство: Встроенный Maven не требует установки, что упрощает начало работы.
Совместимость: IDEA гарантирует совместимость встроенного Maven с функциями IDE (например, автодополнение в POM.xml, интеграция с dependency:tree).
Изоляция: Встроенный Maven изолирован от системных изменений (например, обновления системного Maven), обеспечивая стабильность.
Кэширование: IDEA использует тот же локальный репозиторий (~/.m2/repository), что и системный Maven, минимизируя дублирование данных.


Когда использовать системный Maven:
Для согласованности с CI/CD, где требуется конкретная версия Maven.
При использовании Maven Wrapper (mvnw), который игнорирует встроенный Maven.
Для кастомных расширений или плагинов, требующих специфической версии Maven.
При работе в терминале или на серверах без IDE.

В памяти: Системный Maven запускается как отдельный процесс, что изолирует его от памяти IDEA, но требует дополнительных ресурсов для запуска JVM. Встроенный Maven экономит ресурсы, так как работает в той же JVM, но может конфликтовать с другими задачами IDE.


Нюансы интеграции

Конфликты версий: Если системный и встроенный Maven используют разные версии, могут возникнуть несовместимости в поведении плагинов или разрешении зависимостей. Используйте mvnw или настройте IDEA на системный Maven.
Настройки: Встроенный Maven использует ~/.m2/settings.xml, если он существует, но IDEA позволяет переопределить настройки через интерфейс.
Производительность: Встроенный Maven может быть медленнее в IDE из-за конкуренции за ресурсы JVM. Для крупных проектов рекомендуется системный Maven с -T для параллельной сборки.
Отладка: IDEA предоставляет графический интерфейс для выполнения Maven-целей (Run > Maven > Lifecycle), но для детальной отладки используйте терминал с -X или -e.

#Java #middle #Maven_In_IntelljIDEA

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

Управление памятью:
Maven загружает модель POM, зависимости и плагины в память JVM. Для крупных проектов с сотнями зависимостей потребление памяти может достигать нескольких гигабайт.
Встроенный Maven в IDEA разделяет память с IDE, что может привести к перегрузке при выполнении ресурсоемких задач (например, компиляция или тестирование).
Системный Maven запускается отдельно, что изолирует его, но увеличивает общее потребление памяти системы.
Оптимизируйте с помощью JVM-флагов: -Xmx2048m для увеличения кучи.

Кэширование:
Локальный репозиторий (~/.m2/repository) используется обоими вариантами Maven, минимизируя дублирование артефактов.
Встроенный Maven в IDEA кэширует результаты сборки в памяти IDE, что ускоряет повторные операции, но увеличивает нагрузку на JVM.

Совместимость:
Убедитесь, что версия JDK, указанная в JAVA_HOME, совместима с Maven (например, Maven 3.8.6 требует JDK 7+).
Разные версии Maven могут по-разному интерпретировать POM.xml. Используйте mvnw для согласованности.

Безопасность:
Храните учетные данные для репозиториев в зашифрованном виде в ~/.m2/settings-security.xml.
Ограничьте доступ к ~/.m2 на Linux: chmod 700 ~/.m2.

Отладка:
Используйте mvn -X для вывода подробных логов о загрузке плагинов и зависимостей.
В IDEA откройте вкладку "Maven" для выполнения целей и анализа вывода.
Проверьте итоговую конфигурацию: mvn help:effective-pom или mvn help:effective-settings.

Производительность:
Системный Maven позволяет использовать флаг -T для параллельной сборки, что быстрее для многомодульных проектов.
Встроенный Maven в IDEA может быть ограничен настройками JVM IDE. Настройте idea64.exe.vmoptions для увеличения памяти.

#Java #middle #Maven_In_IntelljIDEA

Подробная инструкция по установке Maven на Windows


Зачем устанавливать Maven

Установка Maven на систему необходима по следующим причинам:
Автоматизация сборки: Maven предоставляет стандартизированный жизненный цикл для компиляции, тестирования, упаковки и развертывания проектов.
Управление зависимостями: Maven автоматически загружает библиотеки из репозиториев (например, Maven Central), упрощая управление зависимостями.
CI/CD-интеграция: CI/CD-системы (Jenkins, GitLab CI, GitHub Actions) требуют системной установки Maven для выполнения сборок.
Независимость от IDE: Системный Maven позволяет запускать команды (mvn clean install) из терминала, что полезно для серверов или скриптов.
Контроль версий: Системная установка позволяет использовать конкретную версию Maven, обеспечивая воспроизводимость сборок.
Кастомизация: Системный Maven дает полный контроль над настройками через settings.xml и поддерживает расширения.

В памяти Maven работает как Java-приложение, загружая модель POM, зависимости и плагины в оперативную память. Установка на систему минимизирует зависимость от IDE, но требует управления версиями и конфигурацией.


Установка Maven на Windows

Требования
JDK: Установленный Java Development Kit (версия 8 или выше, рекомендуется OpenJDK или Oracle JDK).
Интернет: Для загрузки Maven и зависимостей.
Права администратора: Для настройки переменных окружения (опционально).

Шаги установки

Проверка JDK:
Убедитесь, что JDK установлен:

java -version

Вывод должен показать версию Java (например, openjdk 11.0.16). Если JDK отсутствует, скачайте и установите с Adoptium или Oracle.

Скачивание Maven:
Перейдите на официальный сайт Apache Maven.
Скачайте бинарный архив, например, apache-maven-3.9.9-bin.zip.
Распакуйте архив в удобную директорию, например, C:\Program Files\Apache\maven-3.9.9.

Настройка переменных окружения:
Откройте "Свойства системы".
Нажмите Win + R, введите sysdm.cpl и нажмите Enter.
Перейдите на вкладку "Дополнительно" → "Переменные среды".

Создайте переменную M2_HOME:
В разделе "Системные переменные" нажмите "Создать".
Имя: M2_HOME, Значение: C:\Program Files\Apache\maven-3.9.9.

Добавьте Maven в PATH:
Найдите переменную Path в "Системных переменных" и добавьте %M2_HOME%\bin.

Проверьте переменную JAVA_HOME:
Убедитесь, что JAVA_HOME указывает на директорию JDK, например, C:\Program Files\Java\jdk-11.0.16.
Если отсутствует, создайте: Имя: JAVA_HOME, Значение: C:\Program Files\Java\jdk-11.0.16.

Проверка установки:
Откройте командную строку (Win + R → cmd).

Выполните:

mvn -version

Вывод должен показать версию Maven, Java и другие детали:

Apache Maven 3.8.6
Maven home: C:\Program Files\Apache\maven-3.8.6
Java version: 11.0.16, vendor: Adoptium

Настройка локального репозитория:
По умолчанию Maven использует ~/.m2/repository (например, C:\Users\<username>\.m2\repository) для кэширования зависимостей.

Опционально настройте settings.xml в C:\Users\<username>\.m2 для указания зеркал, прокси или профилей:

<settings>
    <localRepository>C:/custom/m2/repository</localRepository>
</settings>

В памяти: При запуске Maven загружает mvn.bat (или mvn.cmd), который вызывает Java-процесс. JVM загружает Maven Core, плагины и зависимости в оперативную память. Локальный репозиторий минимизирует сетевые запросы, но может занимать значительное место на диске.

Нюансы:
Убедитесь, что JAVA_HOME указывает на JDK, а не JRE, иначе Maven не сможет компилировать код.
Если mvn не распознается, проверьте правильность PATH.
Используйте Maven Wrapper (mvnw) в проектах для независимости от системной версии.

#Java #middle #Maven #Maven_install

Установка Maven на Linux

Требования
JDK: Установленный JDK (версия 8 или выше).
Интернет: Для загрузки Maven.
Терминал: Доступ к командной строке.


Шаги установки

Проверка JDK:
Выполните:

java -version

Вывод должен показать версию Java. Если JDK отсутствует, установите, например, OpenJDK:

sudo apt update
sudo apt install openjdk-11-jdk  # Ubuntu/Debian
sudo dnf install java-11-openjdk-devel  # Fedora

Скачивание Maven:
Перейдите на сайт Apache Maven.

Скачайте архив, например, apache-maven-3.9.9-bin.tar.gz:

wget https://downloads.apache.org/maven/maven-3/3.9.9/binaries/apache-maven-3.9.9-bin.tar.gz

Распакуйте в /opt:

sudo tar -xzvf apache-maven-3.9.9-bin.tar.gz -C /opt

Настройка переменных окружения:
Откройте файл /etc/environment или ~/.bashrc:

nano ~/.bashrc

Добавьте строки:

export M2_HOME=/opt/apache-maven-3.9.9
export PATH=$M2_HOME/bin:$PATH
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64  # Путь к JDK

Примените изменения:

source ~/.bashrc

Проверка установки:
Выполните:

mvn -version

Вывод:

Apache Maven 3.9.9
Maven home: /opt/apache-maven-3.9.9
Java version: 11.0.16, vendor: Ubuntu

Настройка локального репозитория:
По умолчанию используется ~/.m2/repository.

Опционально настройте ~/.m2/settings.xml для кастомного пути или зеркал:

<settings>
    <localRepository>/custom/m2/repository</localRepository>
</settings>

В памяти: На Linux Maven запускается через скрипт mvn, который вызывает JVM. Процесс аналогичен Windows: Maven Core, плагины и зависимости загружаются в память. Локальный репозиторий кэширует артефакты, снижая сетевую нагрузку.

Нюансы:
Убедитесь, что JAVA_HOME указывает на правильный JDK.
Для системного доступа установите Maven в /opt и настройте права: sudo chown -R $USER /opt/apache-maven-3.9.9.
Используйте mvnw для согласованности версий в проектах.

#Java #middle #Maven #Maven_install

Введение в 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

Зависимости и конфигурации в Gradle

Dependency Configurations
Конфигурации в Gradle определяют группы зависимостей, используемых для разных целей (компиляция, выполнение, тестирование). Они заменяют концепцию scope в Maven, предоставляя более гибкий подход.


Основные конфигурации

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

Пример:

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

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

api:
Используется для зависимостей, которые становятся частью публичного API модуля и транзитивно передаются потребителям.
Применяется в основном в плагине java-library.

Пример:

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

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

compileOnly:
Зависимости, необходимые только для компиляции, но не для выполнения.
Аналог provided в Maven.

Пример:

dependencies {
    compileOnly 'javax.servlet:javax.servlet-api:4.0.1'
}

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

runtimeOnly:
Зависимости, необходимые только для выполнения, но не для компиляции.
Аналог runtime в Maven.

Пример:

dependencies {
    runtimeOnly 'mysql:mysql-connector-java:8.0.28'
}

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

testImplementation:
Зависимости для компиляции и выполнения тестов.
Не транзитивны для основного кода.

Пример:

dependencies {
    testImplementation 'junit:junit:4.13.2'
}

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

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

Конфигурации в деталях: configurations {}
Gradle позволяет определять кастомные конфигурации через блок configurations для специфических нужд.

Пример:

configurations {
    customConfig
}
dependencies {
    customConfig 'com.example:library:1.0'
}
tasks.register('useCustomConfig') {
    doLast {
        configurations.customConfig.each { file ->
            println "Using ${file.name}"
        }
    }
}

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

Расширение конфигураций: Конфигурации могут наследовать друг от друга:

configurations {
    customConfig.extendsFrom implementation
}

Это добавляет все зависимости implementation в customConfig.

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

#Java #middle #Gradle #Configuration_gradle

Dependency Resolution

Gradle автоматически разрешает зависимости, загружая их из репозиториев (например, Maven Central) и управляя конфликтами версий.


Версионирование, конфликты, форсинг, exclusions

Версионирование:
Зависимости указываются с версией: group:artifact:version.
Поддерживаются динамические версии (например, 1.+) или диапазоны ([1.0,2.0)).

Пример:

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

Конфликты:
Gradle использует стратегию newest-wins (новейшая версия побеждает) для разрешения конфликтов версий.
Пример: Если модуль A требует spring-core:5.3.20, а модуль B — spring-core:5.3.22, Gradle выберет 5.3.22.

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

Форсинг:
Для принудительного использования конкретной версии используйте force:

configurations.all {
    resolutionStrategy {
        force 'org.springframework:spring-core:5.3.20'
    }
}

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

Exclusions:
Исключение транзитивных зависимостей для избежания конфликтов или ненужных библиотек:

dependencies {
    implementation('org.springframework:spring-core:5.3.20') {
        exclude group: 'commons-logging'
    }
}

В памяти: Исключения уменьшают размер графа зависимостей, снижая потребление памяти и вероятность конфликтов.

BOM (Bill of Materials)

BOM — это файл, определяющий согласованные версии зависимостей, аналогично Maven. Gradle поддерживает BOM через платформы (platform).

Пример:

dependencies {
    implementation platform('org.springframework.boot:spring-boot-dependencies:2.7.18')
    implementation 'org.springframework.boot:spring-boot-starter'
}

Как работает:
BOM импортируется как платформа, предоставляя версии для всех зависимостей без необходимости их указания.
Gradle загружает BOM (POM-файл) из репозитория и применяет его версии к зависимостям.

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

Модули и классы зависимостей

Модули: Gradle поддерживает зависимости от других Gradle-проектов (модулей) в многомодульных проектах:

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

Модули добавляются в settings.gradle:include 'module-core', 'module-api'


Классы зависимостей: Gradle разрешает зависимости до уровня JAR-файлов, включаемых в classpath. Для Java-проектов это управляется плагином java или java-library.

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

Dependency Cache и Offline режим

Dependency Cache:
Gradle кэширует зависимости в ~/.gradle/caches/modules-2.
Кэш включает JAR-файлы, POM-файлы и метаданные, что минимизирует сетевые запросы.
Очистка кэша:rm -rf ~/.gradle/caches

Offline режим:
Запустите Gradle с флагом --offline:./gradlew build --offline
Gradle использует только локальный кэш, что полезно для сборок без интернета.
Нюанс: Если зависимость отсутствует в кэше, сборка завершится с ошибкой.

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

#Java #middle #Gradle #Configuration_gradle

Lockfiles (Dependency Locking)

Lockfiles фиксируют точные версии зависимостей для воспроизводимости сборки.

Включение:

dependencyLocking {
    lockAllConfigurations()
}

Генерация:

./gradlew dependencies --write-locks

Создает файлы gradle.lockfile в gradle/ для каждой конфигурации.

Пример lockfile:

org.springframework:spring-core:5.3.20
org.junit:junit:4.13.2

Использование: Gradle использует версии из lockfile, игнорируя динамические версии или новейшие доступные.

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

Gradle Dependency Report (gradle dependencies)

Команда ./gradlew dependencies генерирует отчет о зависимостях для всех конфигураций:

./gradlew dependencies

Вывод (пример):

implementation - Implementation dependencies for the main source set.
\--- org.springframework:spring-core:5.3.20
     \--- commons-logging:commons-logging:1.2
testImplementation - Implementation dependencies for the test source set.
\--- junit:junit:4.13.2

Флаги:
--configuration <name>: Для конкретной конфигурации, например, ./gradlew dependencies --configuration implementation.
-q: Для компактного вывода.


Использование: Анализ транзитивных зависимостей, выявление конфликтов.

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

Variant-aware Resolution

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

Пример:

dependencies {
    implementation 'org.example:library:1.0' {
        attributes {
            attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, 11)
        }
    }
}

Назначение:
Выбор артефакта для конкретной версии Java или платформы (например, Android vs JVM).
Поддержка мультиплатформенных библиотек (например, Kotlin Multiplatform).

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

#Java #middle #Gradle #Configuration_gradle