Apache Maven Einführung für Java

Maven ist das Standard-Build-Automatisierungs- und Abhängigkeitsverwaltungstool für Java. Es wandelt ein Projekt in eine deklarative Beschreibung um — was es ist, wovon es abhängt, wie es gebaut wird — und führt dann den Build für Sie durch. Anstatt JAR-Dateien und javac-Flags manuell zu verwalten, deklarieren Sie Ihre Anforderungen in einer einzigen Datei, und Maven lädt Abhängigkeiten herunter, kompiliert, testet und verpackt Ihren Code durch einen vorhersehbaren, reproduzierbaren Lebenszyklus.

Das POM: ein Projekt als Daten

Jedes Maven-Projekt wird durch eine pom.xml (Project Object Model) beschrieben. Es identifiziert das Projekt mit drei Koordinaten — groupId, artifactId und version (zusammen das "GAV") — und listet die benötigten Bibliotheken auf. Dasselbe Koordinatenschema benennt Ihr Projekt und jede Abhängigkeit, wodurch Maven Artefakte in einem Repository lokalisiert.

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>shop-app</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>6.1.0</version>
    </dependency>
  </dependencies>
</project>

Das <packaging>-Element teilt Maven mit, was es produzieren soll (jar, war, pom). Der <properties>-Block enthält wiederverwendbare Werte — hier das Java-Release, auf das der Compiler abzielt. Das POM wächst, um Plugins, Profile und Vererbung abzudecken; das Maven-POM-Kapitel erläutert diese Teile im Detail.

Abhängigkeiten und der transitive Klassenpfad

Sie listen nur Ihre direkten Abhängigkeiten auf. Maven liest das eigene POM jeder Abhängigkeit und zieht alles heran, was diese benötigen — die transitiven Abhängigkeiten — und erstellt den vollständigen Klassenpfad automatisch. Das Deklarieren von spring-web bringt auch spring-core mit, ohne dass Sie es benennen müssen.

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.17.0</version>
</dependency>

Jede Abhängigkeit hat einen Scope, der steuert, wann sie im Klassenpfad verfügbar ist. Der Standard, compile, macht sie überall verfügbar; test beschränkt sie auf Testcode; provided bedeutet, dass die Laufzeitumgebung sie bereitstellt. Für Versionskonflikte, Ausschlüsse und dependencyManagement siehe Maven-Abhängigkeiten.

Scope	Im Kompilier-Klassenpfad	Im Test-Klassenpfad	Verpackt	Typische Verwendung
`compile` (Standard)	Ja	Ja	Ja	Normale Bibliotheken
`provided`	Ja	Ja	Nein	Servlet API, zur Laufzeit bereitgestellt
`runtime`	Nein	Ja	Ja	JDBC-Treiber
`test`	Nein	Ja	Nein	JUnit, Mockito

Der Build-Lebenszyklus

Maven-Builds laufen durch eine feste Abfolge von Phasen. Die wichtigsten Phasen des Standard-Lebenszyklus sind validate, compile, test, package, verify, install und deploy. Das Ausführen einer Phase führt jede vorherige Phase aus — mvn package validiert, kompiliert und testet zuerst, dann verpackt es. Sie rufen Phasen nie außer der Reihe auf.

mvn compile          # compile main sources
mvn test             # compile + run unit tests
mvn package          # compile + test + build the JAR/WAR
mvn install          # package + copy artifact into your local repository
mvn clean package    # delete target/ first, then build fresh

Jede Phase ist an ein oder mehrere Goals gebunden, die von Plugins bereitgestellt werden (zum Beispiel ist compiler:compile an die compile-Phase gebunden). In Plugins liegt die eigentliche Arbeit; der Lebenszyklus ordnet sie lediglich. Das Kapitel Maven-Build-Lebenszyklus behandelt alle drei eingebauten Lebenszyklen und wie Goals an Phasen gebunden werden.

Repositories

Maven holt Artefakte aus Repositories. Beim Build sucht es zuerst in Ihrem lokalen Repository (~/.m2/repository), einem Cache auf Ihrem Rechner. Bei einem Cache-Miss lädt es aus einem Remote-Repository herunter — standardmäßig Maven Central — und speichert eine Kopie lokal, sodass der nächste Build offline-schnell ist. Teams fügen oft ein privates Repository für interne Bibliotheken hinzu.

project pom.xml  →  local repo (~/.m2)  →  remote repo (Maven Central)
                     (cache hit?)            (download + cache)

Ein ausführbares Beispiel

Der Code-Runner hat kein Maven in seinem Klassenpfad, daher modelliert das folgende Programm Mavens Kernmechanismen mit reinem JDK-Code: Es speichert ein kleines POM als Map, löst den transitiven Abhängigkeitsabschluss auf (dedupliziert gemeinsame Artefakte) und durchläuft den Build-Lebenszyklus, wobei es bei der angeforderten Phase stoppt. Die Strukturen hier — GAV-Koordinaten, transitive Auflösung, geordnete Phasen — entsprechen genau dem, was Maven tatsächlich tut.

java— editable, runs on the server

import java.util.*;

public class Main {
    // A coordinate triple, exactly like Maven's groupId:artifactId:version.
    record Gav(String groupId, String artifactId, String version) {
        @Override public String toString() {
            return groupId + ":" + artifactId + ":" + version;
        }
        String jar() { return artifactId + "-" + version + ".jar"; }
    }

// The project model: each artifact mapped to the dependencies it declares.
    static final Map<String, List<Gav>> pom = new LinkedHashMap<>();

static void declare(Gav a, Gav... deps) { pom.put(a.toString(), List.of(deps)); }

// Build the transitive closure the way Maven resolves a classpath.
    static void resolve(Gav a, Set<String> seen, List<Gav> out) {
        for (Gav d : pom.getOrDefault(a.toString(), List.of())) {
            if (seen.add(d.toString())) {   // de-dupe: each JAR appears once
                out.add(d);
                resolve(d, seen, out);      // then pull in its own dependencies
            }
        }
    }

public static void main(String[] args) {
        Gav app     = new Gav("com.example", "shop-app", "1.0.0");
        Gav web     = new Gav("org.springframework", "spring-web", "6.1.0");
        Gav core    = new Gav("org.springframework", "spring-core", "6.1.0");
        Gav jackson = new Gav("com.fasterxml.jackson.core", "jackson-databind", "2.17.0");
        Gav annot   = new Gav("com.fasterxml.jackson.core", "jackson-annotations", "2.17.0");

declare(app, web, jackson);   // our project's direct dependencies
        declare(web, core);           // spring-web transitively needs spring-core
        declare(jackson, annot);      // jackson-databind needs jackson-annotations
        declare(core);
        declare(annot);

System.out.println("Project coordinates: " + app);
        System.out.println("Direct dependencies:");
        for (Gav d : pom.get(app.toString())) System.out.println("  - " + d);

List<Gav> classpath = new ArrayList<>();
        resolve(app, new HashSet<>(), classpath);
        System.out.println("Resolved classpath has " + classpath.size() + " JARs:");
        for (Gav g : classpath) System.out.println("  - " + g.jar());

List<String> phases = List.of("validate", "compile", "test", "package", "install");
        String goal = "package";
        System.out.println("Executing: mvn " + goal);
        for (String p : phases) {
            System.out.println("  phase " + p + " -> OK");
            if (p.equals(goal)) break;   // stop once the requested phase is reached
        }
        System.out.println("BUILD SUCCESS");
    }
}

Was aus dem Lauf mitzunehmen ist:

Das Projekt und jede Abhängigkeit werden durch dasselbe GAV-Triple benannt, weshalb Project coordinates: com.example:shop-app:1.0.0 genauso aussieht wie eine Abhängigkeitszeile.
Nur zwei Abhängigkeiten werden deklariert, aber der aufgelöste Klassenpfad hat vier JARs — spring-core und jackson-annotations wurden transitiv hereingezogen, genau wie Maven es tut.
Das seen-Set stellt sicher, dass jedes Artefakt nur einmal erscheint; das ist Mavens Deduplizierung, die verhindert, dass eine gemeinsam genutzte Bibliothek zweimal im Klassenpfad landet.
Executing: mvn package führt validate, compile und test vor package aus und stoppt dann — das Ausführen einer Phase führt immer jede frühere Phase in der richtigen Reihenfolge aus.
Der Build stoppt bei package und erreicht nie install, was spiegelt, wie das angeforderte Goal begrenzt, wie weit der Lebenszyklus voranschreitet.

Wann Maven zu verwenden ist

Maven glänzt bei konventionellen Java- und JVM-Projekten: Seine "Convention over Configuration"-Vorgaben (Quellcode in src/main/java, Tests in src/test/java, Ausgabe in target/) bedeuten, dass ein neuer Mitarbeiter jedes Maven-Projekt auf dieselbe Weise bauen kann. Sein deklaratives XML ist leicht zu lesen und zu vergleichen, und die IDE-Unterstützung ist ausgereift. Der Kompromiss ist Ausführlichkeit und begrenzte Flexibilität bei ungewöhnlichen Builds. Wenn Sie skriptgesteuerte, hochgradig angepasste Builds benötigen, ist Gradle die gängige Alternative — es verwendet ein programmierbares Build-Skript anstelle von deklarativem XML, deckt aber denselben Bereich ab: GAV-Koordinaten, transitive Abhängigkeiten und ein Task- (statt Phasen-)Graph.

Nächste Schritte

Maven POM — die vollständige Struktur von pom.xml, einschließlich Plugins und Vererbung.
Maven-Abhängigkeiten — Scopes, Ausschlüsse und das ausführliche Auflösen von Versionskonflikten.
Maven-Build-Lebenszyklus — jede Phase, die drei Lebenszyklen und das Binden von Goals.
Gradle-Einführung — die skriptbasierte Alternative zu Maven.

Übungen

Übung

Was passiert in Maven, wenn Sie 'mvn package' ausführen?

Maven führt jede frühere Lebenszyklusphase (validate, compile, test) aus und verpackt dann das ArtefaktMaven führt nur die package-Phase aus und überspringt Kompilierung und TestsMaven stellt das Artefakt in einem Remote-Repository bereitMaven lädt das JDK vor dem Build herunter