Почему отказался от Gradle?

Почему отказался от Gradle

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

1. Slow Build Times (Медленная сборка)

Многие разработчики сталкиваются с тем, что Gradle медленнее Maven на чистых сборках. Основные причины:

Инициализация Gradle Daemon

# Первый запуск - Gradle запускает daemon в фоне
./gradlew build
# Время: 45 секунд (включая инициализацию JVM)

# Maven
mvn clean install
# Время: 30-35 секунд

Daemon помогает с incremental builds, но первый запуск медленный.

Overhead от Groovy/Kotlin скриптов

// build.gradle - динамический DSL, требует парсинга и компиляции
buildscript {
    dependencies {
        classpath "com.android.tools.build:gradle:${androidGradleVersion}"
    }
}

task myTask {
    doLast {
        println "Это скрипт на Groovy, требует компиляции"
    }
}

<!-- pom.xml - просто XML, быстро парсится -->
<build>
    <plugins>
        <plugin>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
        </plugin>
    </plugins>
</build>

Task Graph Resolution

Gradle выполняет сложный анализ графа зависимостей даже для простых операций:

gradle help
# Даже команда "помощь" требует анализа всех задач

2. Конфигурация vs Декларирование

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

Сложность для новичков

// Gradle - нужно понимать Groovy DSL
plugins {
    id java
    id org.springframework.boot version 3.0.0
}

dependencies {
    implementation org.springframework.boot:spring-boot-starter-web
    testImplementation "org.springframework.boot:spring-boot-starter-test:${springBootVersion}"
}

tasks.named(test) {
    useJUnitPlatform()
}

<!-- Maven - понятно с первого взгляда -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.0.0</version>
    </dependency>
</dependencies>

В Maven очевидно:

• Что подтягивается
• В каком порядке
• Какие версии

В Gradle нужно понимать DSL логику.

Отладка конфигурации

// Gradle: что именно выполняется?
configurations.all {
    resolutionStrategy {
        force "org.apache.commons:commons-lang3:3.12.0"
    }
    exclude group: org.springframework, module: spring-core
}

// Откуда взялась эта версия? Какой модуль её подтянул?
// Нужно запустить градл вывода зависимостей

mvn dependency:tree
# Сразу видны все зависимости и конфликты

3. Gradle Hell (Зависимость от версий)

Gradle Wrapper Версионирование

# gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.6.1-all.zip

Когда вы обновляете Gradle:

# Старые плагины могут сломаться
gradle: 7.6 -> 8.0
# Ваша задача больше не работает!
# Нужно обновлять плагины, которые зависят от Gradle 8.0

В Maven этого нет — просто обновляете версию, и всё работает.

Проблема конфликтов плагинов

plugins {
    id org.gradle.kotlin.kotlin-dsl version 3.0.0
    id com.google.protobuf version 0.9.0  // Требует Gradle 7.1+
    id com.android.application version 7.4.0  // Требует Gradle 7.5+
}
// Невозможно найти версию Gradle, которая удовлетворит все плагины!

4. Непредсказуемое поведение

Incremental Build Issues

Gradle обещает быструю incremental сборку, но часто она ломается:

// Gradle решает, что нужна полная пересборка
// Даже если вы изменили только комментарий!
task processResources {
    doLast {
        println "Зачем это снова выполняется?"
    }
}

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

Daemon Memory Leaks

# После нескольких сборок daemon требует всё больше памяти
ps aux | grep gradle
# GradleDaemon использует 2GB вместо 512MB

# Нужно регулярно перезапускать
./gradlew --stop

5. Слишком много возможностей

Gradle позволяет делать практически всё, но это создаёт:

Боль при maintenance

// Разработчик А создал этот build.gradle
plugins {
    id java
}

// Через 2 года разработчик B добавил:
subprojects {
    repositories {
        maven { url = https://custom-repo.local }
    }
}

// Разработчик C добавил:
task deploy {
    doLast {
        exec { commandLine bash, deploy.sh }
    }
}

// Теперь 500 строк тугого кода, невозможно отдебажить

Convention over Configuration нарушена

// Gradle позволяет переопределить ВСЁ
sourceSets {
    main {
        java {
            srcDirs = [my_custom_sources]
        }
    }
}

classesDir = new File(my_weird_output)
compile {
    destinationDir = file(somewhere)
}

// Теперь новый разработчик не знает, где находятся исходники!

Maven следует Convention over Configuration строго:

├── src/
│   ├── main/java
│   ├── main/resources
│   ├── test/java
│   └── test/resources
├── target/
└── pom.xml

6. Проблемы в экосистеме

IDE Integration

# Gradle Sync в IntelliJ IDEA может зависнуть
Loading Gradle project...
# 5 минут спустя: всё ещё Loading

# Maven делает это быстрее

Reproducible Builds

Gradle сложнее сделать reproducible (одинаковые исходники → одинаковый бинарник):

// Gradle использует динамические версии
dependencies {
    implementation org.springframework.boot:spring-boot-starter-web:+
    // Будет другая версия при каждой сборке!
}

Когда Gradle всё-таки нужен

• Multi-module проекты с нестандартной структурой
• Android development (Android Studio требует Gradle)
• Кастомные задачи (Code generation, DSL)
• Высокие требования к performance (если правильно настроить)
• Kotlin проекты с Gradle Kotlin DSL

Альтернативы

┌────────┬──────────────────┬──────────────────┬──────────────────┐
│ Критерий│    Maven         │     Gradle       │      Bazel       │
├────────┼──────────────────┼──────────────────┼──────────────────┤
│ Скорость│ ✓✓               │ ✓✓✓ (с daemon)   │ ✓✓✓✓             │
│ Простота│ ✓✓✓              │ ✓✓ (DSL)         │ ✗✗ (steep learn) │
│ Гибкость│ ✓✓               │ ✓✓✓✓             │ ✓✓✓              │
│ Android │ ✗                │ ✓✓✓              │ ✓✓               │
│ CI/CD   │ ✓✓✓              │ ✓✓✓              │ ✓✓✓              │
└────────┴──────────────────┴──────────────────┴──────────────────┘

Резюме

Отказ от Gradle оправдан, если:

1. Проект имеет стандартную структуру → Maven справится
2. Сборка должна быть понятной и поддерживаемой → Maven выигрывает
3. Нет специфических требований → зачем усложнять?
4. Есть проблемы с production build временем → Maven может быть быстрее

Для большинства enterprise Java приложений Maven все ещё актуален и часто лучше выбор, чем Gradle.