Projektstruktur und Build-Tools: Maven, Gradle, npm

In L1 hast du IDEs kennengelernt – die Werkstatt, in der du programmierst. Diese Lektion geht eine Ebene tiefer: Build-Tools. Sie sind das, was aus deinem Quellcode ein lauffähiges Programm macht: kompilieren, Abhängigkeiten holen, Tests ausführen, JAR-Datei oder npm-Paket bauen.

Die drei wichtigsten Build-Tools: Maven (Java, XML, klassisch), Gradle (Java/Kotlin, Groovy/Kotlin-Skripte, moderner), npm (JavaScript/TypeScript, JSON). Du lernst die typische Projektstruktur, die Build-Pipeline und die wichtigsten Kommandos für die IHK-Klausur und den Alltag.

1) Was ist ein Build-Tool eigentlich?

Stell dir vor, du willst eine Pizza backen. Ohne Hilfe müsstest du: Mehl kaufen, Tomaten klein hacken, Käse reiben, Teig kneten, Ofen vorheizen, Pizza zusammenbauen, Backen, Reinigen. Mit einem Rezept und einer Küchenmaschine geht das viel strukturierter – jede Phase definiert, Werkzeuge bereit.

Genau das ist ein Build-Tool: ein Rezept-Ausführer für Software. Es liest eine Konfigurationsdatei (z.B. pom.xml), erkennt was zu tun ist (Abhängigkeiten holen, kompilieren, testen, packen), führt es in der richtigen Reihenfolge aus und meldet, ob alles geklappt hat.

Ohne Build-Tool müsste man manuell:

Bibliotheken herunterladen, in der richtigen Version, in den passenden Ordner kopieren.
Alle .java-Dateien kompilieren – mit dem richtigen Klassenpfad.
Tests aufrufen, einzeln.
Verpacken in eine JAR-Datei, mit dem richtigen Manifest.
Bei jeder Änderung das Ganze wiederholen.

Das macht niemand, der bei Verstand ist. Build-Tools automatisieren genau das.

2) Die Build-Pipeline – probier es aus

Eine typische Build-Pipeline läuft in mehreren Phasen ab. Klick auf „Nächste Phase", um durchzulaufen, was passiert:

Build-Pipeline-Simulator

Phase 1: Quellcode – das Build-Tool findet alle Quelldateien im Projekt. Bei Maven/Gradle: src/main/java. Bei npm: src/.

Diese 5 Phasen sind das Grundgerüst jedes Build-Tools. Maven nennt sie offiziell Lifecycle-Phasen (validate, compile, test, package, install, deploy). Gradle nennt sie Tasks. npm nennt sie Scripts. Das Konzept ist dasselbe – nur die Begriffe unterscheiden sich.

3) Maven – der klassische Java-Standard

Apache Maven kam 2004 raus und ist bis heute in vielen Enterprise-Java-Projekten der Standard. Die Konfiguration steht in einer pom.xml („Project Object Model"). Maven setzt stark auf Konventionen: bestimmte Ordnerstrukturen sind vorgegeben, davon weicht man selten ab.

Typische Maven-Projektstruktur:

Maven-Projektstruktur (Konvention)

📁 mein-projekt/ ├── 📄 pom.xml # Build-Konfiguration ├── 📁 src/ │ ├── 📁 main/ │ │ ├── 📁 java/ # Quellcode │ │ │ └── 📁 de/firma/app/ │ │ │ └── 📄 Main.java │ │ └── 📁 resources/ # Configs, Properties │ └── 📁 test/ │ └── 📁 java/ # Test-Code │ └── 📄 MainTest.java └── 📁 target/ # Build-Output, ignoriert └── 📄 mein-projekt-1.0.jar

Wichtig: nicht in target/ arbeiten – das wird bei jedem Build gelöscht. Eigene Quellen immer unter src/main/java. Tests unter src/test/java. Maven findet alles automatisch, wenn diese Konvention eingehalten wird. „Convention over Configuration" ist das Mantra.

4) Die pom.xml im Beispiel

Die pom.xml beschreibt das Projekt: wer baut es, welche Java-Version, welche Bibliotheken, welche Plugins. Hier eine minimale Variante:

Beispiel-pom.xml und Vergleich zu Gradle / npm

pom.xml

<project> <modelVersion>4.0.0</modelVersion> <groupId>de.firma</groupId> <artifactId>mein-projekt</artifactId> <version>1.0.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> <version>5.10.0</version> <scope>test</scope> </dependency> </dependencies> </project>

Beachte die drei Pflichtangaben: groupId (Domain rückwärts, identifiziert den Hersteller), artifactId (Name des Projekts), version (typisch 1.0.0 nach SemVer, siehe K51 L7). Zusammen die GAV-Koordinaten. Klick auf die Tabs oben, um zu sehen, wie dieselbe Konfiguration in Gradle und npm aussieht.

5) Maven-Lifecycle: die Phasen

Maven definiert einen Lifecycle mit 8 Hauptphasen. Wer mvn install ausführt, läuft alle vorherigen Phasen automatisch durch. Das ist eines der Kernkonzepte:

Maven-Lifecycle-Phasen

1. validate

Prüft, ob die pom.xml korrekt ist.

2. compile

Übersetzt Java-Quellcode zu Bytecode (.class).

3. test

Führt die Unit-Tests aus (vgl. K52 L6).

4. package

Packt alles in eine JAR/WAR-Datei.

5. verify

Integration-Tests laufen.

6. install

Installiert in lokales Maven-Repository ~/.m2/.

7. deploy

Lädt in zentrales/Firmen-Repository hoch.

+ clean

Löscht target/ (eigener Lifecycle).

Die Phasen laufen sequentiell und kumulativ: mvn package ruft automatisch validate → compile → test → package auf. Wer einen Phase überspringen will, nutzt -DskipTests. „Konvention statt Konfiguration" wieder: keine Lifecycle-Phasen selbst definieren – die sind vorgegeben.

6) Gradle – die modernere Alternative

Gradle ist 2007 entstanden, hat Maven viele Marktanteile abgenommen, ist heute Standard für Android-Apps und viele moderne Java/Kotlin-Projekte. Statt XML wird eine Groovy- oder Kotlin-DSL verwendet – das ist deutlich knapper und flexibler.

Maven vs. Gradle – die Kerne

Apache MavenXML · seit 2004

Klar strukturiert, konventionsgetrieben. XML-Konfiguration ist verbose, aber jeder versteht sie sofort. Riesiges Plugin-Ökosystem. In großen Konzernen oft gesetzt. Gefühlte Trägheit bei Builds (kein inkrementelles Bauen wie Gradle).

GradleGroovy/Kotlin · seit 2007

Flexibler, schneller. DSL-Skripte sind kürzer als XML, dafür braucht es Programmier-Logik in der Build-Datei. Inkrementelle Builds sind sehr schnell – Gradle merkt sich, was sich geändert hat. Android-Standard, in modernen Projekten erste Wahl.

In der IHK-Klausur reicht es, beide zu kennen und einen Unterschied zu nennen (XML vs. DSL, Lifecycle vs. Tasks). Welches Tool besser ist, kommt aufs Projekt an. Beide nutzen denselben Repository-Ansatz und können dieselben Bibliotheken aus Maven Central holen. Übergänge sind möglich aber Aufwand.

7) npm – die JavaScript-Welt

In JavaScript/TypeScript ist npm (Node Package Manager) das Standard-Tool. Konfigurations-Datei: package.json. Anders als Maven/Gradle ist npm primär ein Paketmanager – das Build-System wird durch Scripts in der package.json implementiert. Mehr zu npm in L3.

Beispiel-package.json (siehe Tab oben): scripts definiert eigene Befehle wie npm test, npm run build, npm start. Was die machen, schreibt man selbst – meist ruft man andere Tools auf (TypeScript-Compiler, Webpack, Vite, Jest).

Typische npm-Projektstruktur ist viel flexibler als bei Maven: src/, dist/ oder build/, node_modules/ für Abhängigkeiten (immer in .gitignore!).

8) Befehls-Cheatsheet

Die wichtigsten Build-Befehle

Aktion	Maven	Gradle	npm
Abhängigkeiten holen	mvn dependency:resolve	gradle dependencies	npm install
Kompilieren	mvn compile	gradle compileJava	npm run build
Tests laufen lassen	mvn test	gradle test	npm test
Verpacken	mvn package	gradle build	npm pack
Alles zusammen	mvn install	gradle build	npm run build
Aufräumen	mvn clean	gradle clean	rm -rf dist

In der IHK-Klausur reicht es, die wichtigsten zu kennen: mvn install, mvn clean, npm install, npm run build. Die Build-Tools sind über das IDE-Menü erreichbar (Run Configurations) – aber wer sie auf der Kommandozeile beherrscht, ist deutlich produktiver.

9) Wrapper-Skripte: Maven Wrapper und Gradle Wrapper

Ein häufiges Problem: jeder Entwickler hat eine andere Maven-/Gradle-Version installiert → Builds schlagen unterschiedlich an. Lösung: Wrapper-Skripte, die in das Projekt eingecheckt werden:

Maven Wrapper: ./mvnw clean install statt mvn .... Lädt automatisch die richtige Maven-Version herunter.
Gradle Wrapper: ./gradlew build statt gradle .... Gleiches Prinzip.

Heute Best Practice: in jedem Projekt einen Wrapper haben. So baut auch ein neuer Entwickler ohne System-Installation alles korrekt: git clone + ./mvnw install, fertig.

10) Build-Cache und Inkrementelle Builds

Bei großen Projekten dauert ein voller Build leicht 5-30 Minuten. Moderne Tools optimieren das mit zwei Mechanismen:

Lokaler Cache: bereits gebaute Module werden zwischengespeichert. Bei wiederholtem Bauen ohne Änderung praktisch sofort fertig.
Inkrementelle Builds: nur die Dateien werden neu kompiliert, die sich geändert haben. Gradle ist hier besonders stark.
Remote Build Cache: die ganze Firma teilt sich einen Cache – wer dieselbe Stelle baut, profitiert vom Cache der Kollegen.

In CI/CD-Pipelines (vgl. K54) macht der Build-Cache den Unterschied zwischen 2-Minuten-Pipelines und 30-Minuten-Pipelines.

Zusammenfassung

Build-Tools automatisieren Kompilieren, Testen, Verpacken und Abhängigkeitsverwaltung. Maven (Java, XML pom.xml, Lifecycle-Phasen: validate → compile → test → package → install → deploy), Gradle (Java/Kotlin, Groovy-DSL, Tasks, inkrementelle Builds, Android-Standard), npm (JavaScript/TypeScript, package.json, Scripts). GAV-Koordinaten: groupId, artifactId, version. Wrapper (./mvnw, ./gradlew) fixieren die Build-Tool-Version pro Projekt. Nächste Lektion: Paketmanager.