Maven ist eines der zentralen Werkzeuge im Java-Ökosystem. Wenn du damit wenig Erfahrung hast, wirkt es am Anfang oft sperrig und unnötig komplex. In der Praxis löst Maven jedoch sehr konkrete Probleme: wiederholbare Builds, saubere Abhängigkeiten und eine klare Projektstruktur. Sobald du das Grundprinzip verstanden hast, wird Maven eher Werkzeug als Hürde.
Was ist Maven
Maven ist ein Build- und Projektmanagement-Tool für Java-Projekte. Es definiert, wie dein Projekt aufgebaut ist, welche Abhängigkeiten es nutzt und wie daraus ein lauffähiges Artefakt entsteht. Dieses Artefakt kann zum Beispiel ein JAR (Java ARchive) oder ein WAR (Web Application ARchive) sein. Der wichtigste Gedanke hinter Maven ist Konvention vor Konfiguration. Anstatt alles selbst festzulegen, bringt Maven feste Regeln mit. Wenn du dich an diese hältst, musst du deutlich weniger konfigurieren. Das spart Zeit und reduziert Fehlerquellen, gerade am Anfang.
Die pom.xml als Herzstück
Das zentrale Element eines Maven-Projekts ist die pom.xml. POM steht für Project Object Model. In dieser Datei beschreibst du dein Projekt. Dazu gehören unter anderem Name, Version, Abhängigkeiten und Build-Konfiguration.
Eine stark vereinfachte pom.xml sieht so aus:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>de.example</groupId>
<artifactId>demo</artifactId>
<version>1.0.0</version>
</project>
Diese vier Angaben reichen bereits, damit Maven dein Projekt eindeutig identifizieren kann. groupId entspricht meist deiner Paketstruktur, artifactId ist der Projektname und version beschreibt den Entwicklungsstand.
Standardverzeichnisstruktur
Maven erwartet eine feste Projektstruktur. Wenn du sie einhältst, erkennt Maven automatisch, wo sich Code, Ressourcen und Tests befinden. Du musst nichts weiter konfigurieren.
Der wichtigste Teil ist src/main/java für produktiven Code und src/test/java für Tests. Ressourcen wie Konfigurationsdateien liegen unter src/main/resources. Diese klare Trennung sorgt dafür, dass Tests nie versehentlich im Produktivartefakt landen.
Gerade für Einsteiger ist das hilfreich, weil du nicht jedes Projekt neu strukturieren musst. Ein Maven-Projekt sieht immer ähnlich aus.
Abhängigkeiten verstehen
Fast kein Java-Projekt kommt ohne externe Libraries aus. Maven kümmert sich darum, diese Abhängigkeiten automatisch herunterzuladen und bereitzustellen.
Eine Abhängigkeit definierst du in der pom.xml:
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>2.0.9</version>
</dependency>
</dependencies>
Maven lädt diese Library aus einem Repository herunter, standardmäßig aus dem Maven Central Repository. Du musst keine JAR-Dateien mehr manuell ins Projekt kopieren. Das vermeidet Versionskonflikte und macht Builds reproduzierbar.
Repositories und lokales Cache
Wenn Maven eine Abhängigkeit lädt, wird sie lokal gespeichert, üblicherweise im .m2-Verzeichnis in deinem Benutzerordner. Dieses lokale Repository fungiert als Cache. Beim nächsten Build wird die Library von dort verwendet und nicht erneut aus dem Internet geladen.
Das ist der Grund, warum ein Maven-Build beim ersten Mal länger dauert und danach deutlich schneller ist.
Plugins als Erweiterung
Maven selbst kann nur sehr wenig. Fast alles, was Maven tatsächlich tut, erledigen Plugins. Kompilieren, Testen, Packen oder Deployen sind Plugin-Aufgaben.
Ein Plugin wird meist indirekt verwendet. Du rufst zum Beispiel einen Build-Phase auf und Maven weiß, welches Plugin dafür zuständig ist. Du kannst Plugins aber auch explizit konfigurieren, wenn du vom Standard abweichen willst.
Der Maven Build Cycle
Der Maven Build Cycle ist der Kern von Maven. Er beschreibt den Ablauf, wie aus deinem Quellcode ein fertiges Artefakt wird. Dieser Ablauf ist in Phasen unterteilt. Jede Phase führt definierte Schritte aus.
Der wichtigste Build Cycle ist der default Lifecycle. Er besteht aus mehreren Phasen, von denen die folgenden für Einsteiger besonders relevant sind.
validate
In der validate-Phase prüft Maven, ob das Projekt grundsätzlich korrekt ist. Dazu gehört unter anderem, ob die pom.xml valide ist und alle notwendigen Informationen vorhanden sind. Es wird noch kein Code kompiliert.
Diese Phase fällt oft nicht auf, weil sie sehr schnell durchläuft, ist aber wichtig für frühe Fehlererkennung.
compile
In der compile-Phase wird dein Java-Code kompiliert. Maven nutzt dafür das entsprechende Compiler-Plugin. Der Quellcode aus src/main/java wird in Bytecode übersetzt und im target-Verzeichnis abgelegt.
Fehler in dieser Phase sind klassische Compilerfehler wie fehlende Klassen oder Syntaxprobleme.
test
Die test-Phase führt automatisierte Tests aus. Dabei werden ausschließlich Tests aus src/test/java berücksichtigt. Der Produktivcode wird nicht erneut kompiliert, sondern der bereits kompilierte Code aus der vorherigen Phase genutzt.
Wenn ein Test fehlschlägt, bricht der Build ab. Das ist gewollt, da ein fehlerhaftes Projekt nicht weiterverarbeitet werden soll.
package
In der package-Phase wird das Artefakt gebaut. Abhängig vom Projekttyp entsteht hier zum Beispiel ein JAR oder WAR. Dieses Artefakt liegt anschließend im target-Verzeichnis.
Ab hier hast du ein lauffähiges Ergebnis deines Projekts.
verify
Die verify-Phase führt zusätzliche Prüfungen durch. Das können Integrationstests oder Qualitätschecks sein. In einfachen Projekten passiert hier oft nichts Sichtbares, da keine zusätzlichen Plugins konfiguriert sind.
install
In der install-Phase wird das erzeugte Artefakt in dein lokales Maven-Repository installiert. Dadurch können andere lokale Projekte dieses Artefakt als Abhängigkeit verwenden.
Das ist besonders relevant in Multi-Modul-Projekten oder bei internen Libraries.
deploy
Die deploy-Phase ist der letzte Schritt. Hier wird das Artefakt in ein entferntes Repository hochgeladen, zum Beispiel in ein internes Firmen-Repository. Für lokale Entwicklung wird diese Phase oft nicht genutzt.
Phasen bauen aufeinander auf
Ein wichtiger Punkt: Wenn du eine Phase ausführst, werden alle vorherigen Phasen automatisch mit ausgeführt. Wenn du also mvn package aufrufst, laufen validate, compile und test automatisch davor.
Das sorgt für einen klar definierten und reproduzierbaren Build-Prozess.
mvn clean package
Dieser Befehl löscht zuerst das target-Verzeichnis und führt anschließend den kompletten Build bis zur package-Phase aus.
Maven im Alltag
Im Alltag arbeitest du selten bewusst mit einzelnen Plugins oder Phasen. Du nutzt wenige Standardbefehle, die zuverlässig funktionieren. Gerade in Kombination mit IntelliJ ist Maven meist im Hintergrund aktiv und nimmt dir viel Arbeit ab.
Wenn du Maven nicht nur als notwendiges Übel, sondern als festen Bestandteil deines Projekts verstehst, wird es schnell zu einem stabilen Fundament für saubere Java-Projekte.
