Gradle vs. Maven: Welches Build-Tool für Java-Projekte?

Im Java-Ökosystem gibt es zwei dominierende Build-Tools: Maven und Gradle. Beide verwalten Dependencies, kompilieren Code, führen Tests aus und erzeugen deploybare Artefakte. Für PHP-Entwickler ist Composer der nächste Vergleich — aber Maven und Gradle machen deutlich mehr als Composer: Sie sind vollwertige Build-Systeme.

Maven: Deklarativ und konventionsbasiert¶

Maven wurde 2004 eingeführt und ist bis heute weit verbreitet. Es basiert auf dem Prinzip "Convention over Configuration" — wer die Standard-Verzeichnisstruktur nutzt, muss wenig konfigurieren.

pom.xml — Das Herzstück¶

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 ...">

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <java.version>21</java.version>
        <spring-boot.version>3.2.0</spring-boot.version>
    </properties>

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

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

Maven Build-Lifecycle¶

Maven nutzt einen festen Lifecycle mit Phasen:

validate → compile → test → package → verify → install → deploy

Häufige Befehle:

./mvnw compile          # Nur kompilieren
./mvnw test             # Tests ausführen
./mvnw package          # JAR/WAR erzeugen (überspringt Tests nicht)
./mvnw package -DskipTests  # JAR ohne Tests
./mvnw spring-boot:run  # Anwendung starten
./mvnw dependency:tree  # Dependency-Baum anzeigen

Maven-Vorteile¶

• Weit verbreitet: Riesiges Ökosystem, fast alle Java-Bibliotheken haben Maven-Koordinaten
• Stabile Konventionen: Jeder Java-Entwickler kennt die Standard-Verzeichnisstruktur
• Reproduzierbar: XML ist deklarativ, kein imperativer Code in Build-Skripten
• IDE-Support: Hervorragende Integration in IntelliJ IDEA, Eclipse, NetBeans
• BOM (Bill of Materials): Dependency-Versionen zentral verwalten

Maven-Nachteile¶

• Verbose XML: Für komplexere Anpassungen wird das pom.xml schnell unübersichtlich
• Performance: Keine inkrementellen Builds, kein Build-Cache (ohne Plugins wie Develocity)
• Erweiterbarkeit: Eigene Logik erfordert Maven-Plugins, die aufwendig zu entwickeln sind

Gradle: Programmatisch und flexibel¶

Gradle wurde 2012 eingeführt und hat Maven in Performance und Flexibilität erheblich übertroffen. Android-Projekte nutzen ausschließlich Gradle; im Spring-Ökosystem ist es die zweite Wahl neben Maven.

build.gradle (Groovy DSL)¶

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.2.0'
    id 'io.spring.dependency-management' version '1.1.4'
}

group = 'com.example'
version = '1.0.0'

java {
    sourceCompatibility = JavaVersion.VERSION_21
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'org.postgresql:postgresql'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

test {
    useJUnitPlatform()
}

build.gradle.kts (Kotlin DSL — empfohlen für neue Projekte)¶

plugins {
    java
    id("org.springframework.boot") version "3.2.0"
    id("io.spring.dependency-management") version "1.1.4"
}

group = "com.example"
version = "1.0.0"

java {
    sourceCompatibility = JavaVersion.VERSION_21
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    runtimeOnly("org.postgresql:postgresql")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.test {
    useJUnitPlatform()
}

Gradle Build-Befehle¶

./gradlew compileJava        # Kompilieren
./gradlew test               # Tests
./gradlew bootJar            # Spring Boot JAR
./gradlew bootRun            # Anwendung starten
./gradlew dependencies       # Dependency-Baum
./gradlew tasks              # Alle verfügbaren Tasks

Gradle-Vorteile¶

• Performance: Inkrementelle Builds (nur geänderte Dateien werden neu gebaut), Build-Cache
• Flexibilität: Eigene Tasks in Groovy/Kotlin schreiben — keine Plugin-Entwicklung nötig
• Multi-Projekt-Builds: Sehr gute Unterstützung für Monorepos mit vielen Subprojekten
• Parallelisierung: Tasks können parallel ausgeführt werden

Gradle-Nachteile¶

• Lernkurve: Groovy/Kotlin DSL ist mächtiger, aber anfangs schwerer verständlich als XML
• Build-Skript-Komplexität: Mit Freiheit kommt Verantwortung — Gradle-Builds können unübersichtlich werden
• Debugging: Probleme in Build-Skripten sind manchmal schwerer zu diagnostizieren

Direkte Gegenüberstellung¶

Was soll man wählen?¶

Maven wählen, wenn:

• Das Team noch keine Erfahrung mit Gradle hat und schnell starten möchte
• Konsistenz und Konventionen wichtiger sind als Flexibilität
• Das Projekt eine Standard-Spring-Boot-Anwendung ist ohne spezielle Build-Anforderungen

Gradle wählen, wenn:

• Android-Entwicklung involviert ist (Pflicht)
• Große Monorepos oder Multi-Modul-Projekte gebaut werden
• Build-Performance ein Thema ist (große Codebasis, viele Tests)
• Eigene Build-Logik nötig ist (Custom-Tasks, Code-Generation, Asset-Processing)

Fazit¶

Für typische Spring-Boot-Projekte ist Maven die sichere, battle-tested Wahl. Wer mehr Kontrolle über den Build-Prozess braucht, in einem Monorepo arbeitet oder Build-Performance optimieren möchte, sollte Gradle wählen — besonders mit der Kotlin DSL, die typsichere Build-Skripte ermöglicht.