Maven gegen Gradle: was Einsteiger brauchen, um das JVM-Projekt einer anderen Person zu bauen

Worum es geht

Maven: pom.xml deklariert Koordinaten (groupId, artifactId, version), Abhängigkeiten mit Scopes und Plugins. Der Lifecycle-Guide hält fest, dass es drei eingebaute Lebenszyklen gibt (default, clean, site); der Default-Lebenszyklus durchläuft seine Phasen in fester Reihenfolge, und das Aufrufen einer Phase führt alle vorherigen ebenfalls aus, sodass mvn verify validiert, kompiliert, testet, packt und Integrationsprüfungen ausführt. Plugin-Goals sind an Phasen gebunden. Abhängigkeits-Scopes (standardmässig compile, dazu provided, runtime, test und import für BOMs) entscheiden, welche Classpaths eine Abhängigkeit erreicht. Der Dependency-Guide hält fest, dass widersprüchliche Versionen durch die "nächstgelegene Definition" im Baum vermittelt werden, wobei bei gleicher Tiefe die erste Deklaration gewinnt, und dass dependencyManagement Versionen für transitive Abhängigkeiten festlegt.

Gradle: Der Basics-Guide beschreibt einen Build anhand von Projekten und Tasks, die durch Build-Skripte (build.gradle in Groovy oder build.gradle.kts in Kotlin) sowie eine settings.gradle(.kts)-Datei konfiguriert werden, wobei Plugins Tasks und Konventionen ergänzen. Abhängigkeiten werden in Konfigurationen wie implementation und testImplementation deklariert. Fordern zwei Pfade unterschiedliche Versionen eines Moduls an, hält das Kapitel zur Konfliktauflösung fest, dass Gradle standardmässig die höchste der angeforderten Versionen wählt. Gradle bietet optionales Abhängigkeits-Locking; Maven hat keine eingebaute Lock-Datei, weshalb Wiederholbarkeit von exakten Versionen und BOM-Importen kommt.

Warum es wichtig ist

Wer an npm, cargo oder pip gewöhnt ist, muss zuerst herausfinden, welches Tool und welche Version das Repository erwartet. Beide Ökosysteme antworten mit einem im Repository committeten Wrapper: ./gradlew, den die Gradle-Dokumentation als empfohlenen Weg zum Ausführen eines Builds bezeichnet, und Mavens optionales ./mvnw. Ein global installiertes Tool in einer anderen Version auszuführen ist der häufigste erste Fehler, gefolgt von der Annahme, die Konfliktregel des jeweils anderen Tools gelte.

So wird es angewendet

• Den Wrapper verwenden: ./gradlew build oder ./mvnw verify; nur auf eine globale Installation zurückgreifen, wenn kein Wrapper existiert.
• Maven: pom.xml von oben nach unten lesen (parent, properties, dependencyManagement, dependencies, build plugins); mvn dependency:tree zeigt, was die Vermittlung gewählt hat.
• Gradle: settings.gradle(.kts) für die Projektliste lesen, dann das Build-Skript; ./gradlew tasks und ./gradlew dependencies --configuration runtimeClasspath erklären den Build.
• Tests sichtbar und nur für lokale Iteration überspringen: -DskipTests (Maven), -x test (Gradle).
• Multi-Modul-Builds: Mavens Reactor ordnet Module anhand ihrer Abhängigkeiten aus dem Root-POM; Gradle-Subprojekte werden in der Settings-Datei aufgeführt.

Stolpersteine

Mavens Regel der nächstgelegenen Definition kann eine ältere Version wählen, als eine transitive Abhängigkeit benötigt; Gradles Regel der höchsten Version kann eine neuere Version hereinziehen, als je ein Modul getestet wurde. Gradle-Build-Skripte sind Code und können alles tun. mvn install schreibt ins lokale Repository und kann eine fehlende Veröffentlichung verdecken. Beide cachen heruntergeladene Artefakte, weshalb CI-Caches einen aus den Build-Dateien abgeleiteten Schlüssel brauchen.