Von Elyndra Valen, Senior Entwicklerin & Code-Archäologin bei Java Fleet Systems Consulting in Essen-Rüttenscheid

Builds

🔌 Was du in 30 Sekunden lernst

Das Problem: Dein Build macht compile, test, package – aber du brauchst Code-Quality-Checks, Security-Scans, Test-Coverage, JavaDoc-Generation, und das alles automatisiert.

Die Lösung: Maven’s Plugin-Ökosystem verstehen und professionell einsetzen.

Was du am Ende hast:

  • Production-Ready Build-Pipeline
  • Automatische Code-Quality-Gates
  • Security-Vulnerability-Scanning
  • Test-Coverage-Reports
  • Performance-optimierte Builds
  • Maven Wrapper für reproduzierbare Builds

Hi, Entwickler-Gilde! 👋

Elyndra hier – und willkommen zum großen Finale der Maven-Serie!

Kurzer Rückblick – Was wir erreicht haben:

  • Teil 1: pom.xml Anatomie verstanden – Projekt-Struktur, GAV-Koordinaten, Properties
  • Teil 2: Dependency Management gemeistert – Scopes, transitive Dependencies, Konflikte lösen
  • Teil 3: Build-Lifecycle & Profiles – Multi-Environment Deployments wie die Profis

Heute: Das Sahnehäubchen – Maven Plugins für professionelle Build-Pipelines!

🚨 Novas Plugin-Desaster vom Donnerstag

Donnerstag, 14:30 Uhr: Nova kommt aufgeregt zu mir.

Nova: „Elyndra, ich hab jetzt automatic Code-Quality-Checks hinzugefügt! Checkstyle, SpotBugs, PMD, Jacoco, SonarQube, FindBugs…“

Ich: „FindBugs? Das ist seit 2016 deprecated… aber okay, lass mal schauen.“

Ich starte ihren Build:

mvn clean package -Pprod  # Nur dann läuft Security-Scan

📦 Build & Packaging Plugins

8. Maven Jar Plugin

Was es macht: Konfiguriert wie dein JAR gebaut wird

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.3.0</version>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <mainClass>de.javafleet.Application</mainClass>
                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
            </manifest>
            <manifestEntries>
                <Built-By>${user.name}</Built-By>
                <Build-Time>${maven.build.timestamp}</Build-Time>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

Fügt MANIFEST.MF hinzu mit:

  • Main-Class für java -jar
  • Version-Informationen
  • Build-Timestamp

9. Maven Shade Plugin

Was es macht: Erstellt „Fat JAR“ mit allen Dependencies drin

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.5.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>de.javafleet.Application</mainClass>
                    </transformer>
                </transformers>
                <filters>
                    <filter>
                        <!-- Exclude signatures -->
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

Ergebnis: myapp-1.0.0.jar (50 MB) mit allen Dependencies – ein einziges JAR zum Deployen!

Wann nutzen: Standalone-Apps, Lambda-Functions, wenn du nicht mit Dependencies jonglieren willst.

10. Spring Boot Maven Plugin

Was es macht: Baut Spring Boot executable JAR

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>3.2.0</version>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <excludes>
            <exclude>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
            </exclude>
        </excludes>
    </configuration>
</plugin>

Macht aus: myapp-1.0.0.jar (2 KB)
Ein: myapp-1.0.0.jar (50 MB) executable mit embedded Tomcat!

📚 Documentation Plugins

11. Maven JavaDoc Plugin

Was es macht: Generiert API-Dokumentation aus JavaDoc-Comments

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>3.6.0</version>
    <configuration>
        <show>private</show>
        <nohelp>true</nohelp>
        <encoding>UTF-8</encoding>
        <failOnError>false</failOnError>
    </configuration>
    <executions>
        <execution>
            <id>attach-javadocs</id>
            <goals>
                <goal>jar</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Erstellt: target/myapp-1.0.0-javadoc.jar

Nutzen: Für Libraries die du veröffentlichst – IDEs können dann JavaDoc anzeigen!

12. Maven Site Plugin

Was es macht: Generiert komplette Projekt-Website

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <version>3.12.1</version>
</plugin>

mvn site

Erstellt in target/site/:

  • Project-Info
  • Dependency-Reports
  • Test-Coverage
  • Code-Quality-Reports
  • JavaDoc

Perfekt für: Open-Source-Projekte, Team-Dokumentation

⚡ Performance Optimization

Parallel Builds

# Nutze alle CPU-Cores
mvn clean install -T 1C

# Nutze 4 Threads
mvn clean install -T 4

Achtung: Nicht alle Plugins sind thread-safe! Teste vorher.

Incremental Compilation

Der Compiler-Plugin macht das automatisch, aber du kannst es optimieren:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <useIncrementalCompilation>true</useIncrementalCompilation>
    </configuration>
</plugin>

Build-Cache (Maven 3.9+)

# Aktiviere lokalen Build-Cache
mvn clean install -Dmaven.build.cache.enabled=true

Spart Zeit: Unveränderte Module werden nicht neu gebaut!

🎯 Production-Ready Build Configuration

Hier ist mein komplettes Setup für Production-Projekte:

<?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 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>de.javafleet</groupId>
    <artifactId>production-app</artifactId>
    <version>1.0.0</version>

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

    <properties>
        <java.version>17</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <jacoco.minimum.coverage>0.80</jacoco.minimum.coverage>
    </properties>

    <build>
        <plugins>
            <!-- Compiler -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                    <compilerArgs>
                        <arg>-parameters</arg>
                        <arg>-Xlint:all</arg>
                    </compilerArgs>
                </configuration>
            </plugin>

            <!-- Unit Tests -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.1.2</version>
            </plugin>

            <!-- Integration Tests -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>3.1.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>integration-test</goal>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

            <!-- Test Coverage -->
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.10</version>
                <executions>
                    <execution>
                        <id>prepare-agent</id>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>test</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>check</id>
                        <goals>
                            <goal>check</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <rule>
                                    <element>PACKAGE</element>
                                    <limits>
                                        <limit>
                                            <counter>LINE</counter>
                                            <value>COVEREDRATIO</value>
                                            <minimum>${jacoco.minimum.coverage}</minimum>
                                        </limit>
                                    </limits>
                                </rule>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- Code Style -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>3.3.0</version>
                <configuration>
                    <configLocation>google_checks.xml</configLocation>
                    <failsOnError>true</failsOnError>
                </configuration>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

            <!-- Spring Boot Executable JAR -->
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <!-- Security Scan - nur für Production -->
        <profile>
            <id>security</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.owasp</groupId>
                        <artifactId>dependency-check-maven</artifactId>
                        <version>8.4.0</version>
                        <configuration>
                            <failBuildOnCVSS>7</failBuildOnCVSS>
                        </configuration>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>check</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>com.github.spotbugs</groupId>
                        <artifactId>spotbugs-maven-plugin</artifactId>
                        <version>4.7.3.6</version>
                        <configuration>
                            <effort>Max</effort>
                            <threshold>Low</threshold>
                        </configuration>
                        <executions>
                            <execution>
                                <phase>verify</phase>
                                <goals>
                                    <goal>check</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>

Build-Commands:

# Development: Schneller Build
mvn clean package

# CI/CD: Mit allen Tests
mvn clean verify

# Production: Full Security Scan
mvn clean verify -Psecurity

🎁 Maven Wrapper – Das Missing Piece

Problem: Jeder Entwickler hat eine andere Maven-Version → „Works on my machine“

Lösung: Maven Wrapper – Maven-Version im Projekt festlegen!

Maven Wrapper Setup

# Einmalig im Projekt ausführen
mvn wrapper:wrapper -Dmaven=3.9.4

Erstellt:

  • .mvn/wrapper/maven-wrapper.jar
  • .mvn/wrapper/maven-wrapper.properties
  • mvnw (Unix)
  • mvnw.cmd (Windows)

Ab jetzt nutzen alle:

# Statt mvn clean install
./mvnw clean install

# Windows
mvnw.cmd clean install

Vorteil:

  • Projekt definiert Maven-Version
  • Neue Teammitglieder brauchen nur JDK, nicht Maven
  • CI/CD nutzt automatisch richtige Version
  • In Git committen!

.gitignore anpassen:

# Maven
target/
!.mvn/wrapper/maven-wrapper.jar

Bernd’s Weisheit: „2015 hatte unser CI-Server Maven 3.1, lokale Entwickler 3.2, Production-Server 3.0. Rate mal wie oft Builds nur in einer Umgebung funktionierten? Maven Wrapper hätte uns Monate erspart!“

Private Log-Moment: Als ich Maven Wrapper das erste Mal gesehen habe, dachte ich: „Das ist doch nur ein Wrapper-Script, was soll’s?“ Dann kam ein neuer Junior-Dev ins Team – hatte Maven 3.0 installiert, Build funktionierte nicht, 3 Stunden Debugging. Seitdem predige ich Maven Wrapper wie eine Religion. Marcus lacht darüber, aber ich sage ihm: Ein gutes Werkzeug braucht keine Versionskonflikte – genau wie deine Hobel! 🔧

🎯 Was du jetzt geschafft hast – Die komplette Maven-Mastery!

Nach dieser 4-teiligen Serie kannst du:

Teil 1 – Grundlagen

✅ pom.xml Struktur verstehen und selbst erstellen
✅ groupId/artifactId/version richtig definieren
✅ Properties nutzen für zentrale Konfiguration
✅ Parent POMs und Vererbung verstehen

Teil 2 – Dependency Management

✅ Dependencies vs Plugins unterscheiden
✅ Scopes richtig einsetzen (compile/test/provided/runtime)
✅ Transitive Dependencies nachvollziehen
✅ Dependency-Tree analysieren mit mvn dependency:tree
✅ Versionskonflikte erkennen und lösen
✅ dependencyManagement professionell nutzen

Teil 3 – Build & Profiles

✅ Maven Build-Lifecycle komplett erklären
✅ Build-Phasen gezielt nutzen (compile/test/package/install)
✅ Profiles erstellen für dev/test/prod
✅ Resource-Filtering für dynamische Konfiguration
✅ Multi-Environment Deployments aufsetzen
✅ Secrets sicher handhaben

Teil 4 – Plugins & Advanced

✅ Essential Plugins konfigurieren (compiler, surefire, failsafe)
✅ Code-Quality automatisieren (Checkstyle, SpotBugs, JaCoCo)
✅ Security-Scanning integrieren (OWASP Dependency Check)
✅ Test-Coverage messen und enforc en
✅ Production-Ready Builds erstellen
✅ Maven Wrapper nutzen für reproduzierbare Builds
✅ Build-Performance optimieren

Dein neues Maven Mental Model:

  • Maven ist nicht kompliziert – es ist systematisch!
  • Plugins erweitern Maven mit beliebigen Funktionen
  • Nicht alle Plugins bei jedem Build laufen lassen (Profiles!)
  • Maven Wrapper ist kein Nice-to-Have – es ist Standard
  • Automatisierung ist der Schlüssel zu Qualität

💬 Community Feedback & Novas Transformation

Nova kam nach der Serie zu mir:

Nova: „Elyndra, ich hab jetzt mein ganzes Projekt umgebaut. Maven Wrapper, Profiles für dev/test/prod, JaCoCo mit 85% Coverage-Minimum, Checkstyle läuft automatisch… und der Build ist trotzdem schneller als vorher!“

Ich: „Wie hast du das gemacht?“

Nova: „Security-Plugins nur im Production-Profile, Tests parallel mit -T 1C, und ich nutze jetzt mvn compile während ich entwickle statt immer mvn clean install!“

Ich: „Das ist genau der Spirit! Du bist jetzt kein Junior-Developer mehr – du bist ein Maven-Professional!“ 😊

Private Log-Moment: Novas Entwicklung in diesen 4 Wochen zu sehen war… emotional. Sie erinnert mich an mich selbst vor Jahren – unsicher, aber wissbegierig. Als sie mir ihre umgebaute pom.xml zeigte, hatte ich fast Tränen in den Augen. Marcus sagt immer: „Die besten Schüler übertreffen irgendwann den Meister.“ Ich glaube, Nova ist auf dem besten Weg dahin. Und das macht mich stolzer als jeder eigene Success! 🌟

🎓 Maven-Serie abgeschlossen – Was kommt als Nächstes?

Du hast jetzt die komplette Maven-Foundation!

Nächste Schritte für deine Projekte:

  1. Maven Wrapper in allen Projekten einführen
  2. Profiles für mindestens dev/prod aufsetzen
  3. JaCoCo mit 80% Minimum aktivieren
  4. Checkstyle oder SpotBugs hinzufügen
  5. CI/CD Pipeline bauen die alles automatisch prüft

Weiterführende Themen:

  • Multi-Module Projekte – Große Anwendungen strukturieren
  • Custom Maven Plugins – Eigene Build-Steps schreiben
  • Maven BOM (Bill of Materials) – Dependency-Management advanced
  • Nexus/Artifactory – Private Repositories betreiben

📧 Deine Maven-Fragen

Ich will von dir hören!

📧 elyndra.valen@java-developer.online

Schick mir:

  • Deine Maven-Horror-Stories
  • Fragen zu spezifischen Plugins
  • Screenshots deiner Build-Pipelines
  • Wünsche für zukünftige Tutorials

Die besten Fragen beantworte ich im nächsten Blogpost!

Private Log-Moment: Diese Maven-Serie war eine der befriedigendsten Dinge, die ich je geschrieben habe. Nicht wegen der Technik – sondern weil ich sehe, wie Nova und andere daraus lernen. Marcus sagt immer: „Wissen teilen ist wie eine Kerze anzünden – sie verliert nichts, aber erhellt alles.“ Er meint seine Tischler-Lehrlinge, aber das gilt auch für uns. Und wenn ich abends nach Hause komme und er fragt „Wie war dein Tag?“, kann ich sagen: „Ich habe jemandem geholfen, besser zu werden.“ Das ist mehr wert als jeder Code. 💝

❓ FAQ – Finale Edition

Frage 1: „Sollte ich alle diese Plugins in jedem Projekt nutzen?“
Antwort: Nein! Start mit Basics (compiler, surefire, jacoco). Füge weitere Plugins hinzu wenn du sie brauchst. Quality-Plugins in Profile auslagern für optionale Ausführung.

Frage 2: „Maven Wrapper in Git committen?“
Antwort: JA! Die .mvn/ Directory und mvnw/mvnw.cmd gehören ins Repo. Nur target/ bleibt in .gitignore.

Frage 3: „Welches Plugin für Fat JARs: Shade oder Spring Boot Plugin?“
Antwort: Spring Boot = Spring Boot Plugin (macht mehr als nur Fat JAR). Nicht-Spring = Shade Plugin. Beide funktionieren, aber Spring Boot Plugin ist optimiert für Spring.

Frage 4: „Kann ich Maven und Gradle in einem Projekt mischen?“
Antwort: Technisch ja, praktisch NIEMALS! Pick one. Maven für Enterprise/Stabilität, Gradle für Flexibilität/Kotlin. Aber niemals beide!

Frage 5: „Wie oft sollte ich mvn clean laufen lassen?“
Antwort: Nur wenn: 1) Komische Fehler auftreten, 2) Du Dependencies geändert hast, 3) Vor Release-Builds. Im normalen Development-Flow: nicht nötig, macht nur langsamer.

Frage 6: „Was ist besser für CI/CD: mvn install oder mvn deploy?“
Antwort: Kommt drauf an! install wenn nur lokaler Build. deploy wenn Artifact zu Nexus/Artifactory soll. In CI meist: mvn clean verify (ohne install/deploy) oder mvn deploy nur für Master-Branch.

Frage 7: „Maven ist so langsam – sollte ich zu Gradle wechseln?“
Antwort: Erst optimieren! Parallel Builds (-T), incremental compilation, Build-Cache, unnötige Plugins in Profiles. Maven 3.9+ mit Cache ist verdammt schnell! Gradle ist nicht automatisch schneller.

Frage 8: „Kann ich mehrere Plugins in der gleichen Phase laufen lassen?“
Antwort: Ja! Sie laufen in der Reihenfolge wie sie in der pom.xml definiert sind. Nutze <execution><phase> um Reihenfolge zu kontrollieren.

❓ FAQ – Finale Edition

Frage 1: „Sollte ich alle diese Plugins in jedem Projekt nutzen?“
Antwort: Nein! Start mit Basics (compiler, surefire, jacoco). Füge weitere Plugins hinzu wenn du sie brauchst. Quality-Plugins in Profile auslagern für optionale Ausführung.

Frage 2: „Maven Wrapper in Git committen?“
Antwort: JA! Die .mvn/ Directory und mvnw/mvnw.cmd gehören ins Repo. Nur target/ bleibt in .gitignore.

Frage 3: „Welches Plugin für Fat JARs: Shade oder Spring Boot Plugin?“
Antwort: Spring Boot = Spring Boot Plugin (macht mehr als nur Fat JAR). Nicht-Spring = Shade Plugin. Beide funktionieren, aber Spring Boot Plugin ist optimiert für Spring.

Frage 4: „Kann ich Maven und Gradle in einem Projekt mischen?“
Antwort: Technisch ja, praktisch NIEMALS! Pick one. Maven für Enterprise/Stabilität, Gradle für Flexibilität/Kotlin. Aber niemals beide!

Frage 5: „Wie oft sollte ich mvn clean laufen lassen?“
Antwort: Nur wenn: 1) Komische Fehler auftreten, 2) Du Dependencies geändert hast, 3) Vor Release-Builds. Im normalen Development-Flow: nicht nötig, macht nur langsamer.

Frage 6: „Was ist besser für CI/CD: mvn install oder mvn deploy?“
Antwort: Kommt drauf an! install wenn nur lokaler Build. deploy wenn Artifact zu Nexus/Artifactory soll. In CI meist: mvn clean verify (ohne install/deploy) oder mvn deploy nur für Master-Branch.

Frage 7: „Maven ist so langsam – sollte ich zu Gradle wechseln?“
Antwort: Erst optimieren! Parallel Builds (-T), incremental compilation, Build-Cache, unnötige Plugins in Profiles. Maven 3.9+ mit Cache ist verdammt schnell! Gradle ist nicht automatisch schneller.

Frage 8: „Kann ich mehrere Plugins in der gleichen Phase laufen lassen?“
Antwort: Ja! Sie laufen in der Reihenfolge wie sie in der pom.xml definiert sind. Nutze <execution><phase> um Reihenfolge zu kontrollieren.

🎉 Das war’s – die komplette Maven-Serie!

Du hast jetzt alles was du brauchst für professionelle Java-Builds. Von Grundlagen über Dependency-Management bis zu Production-Ready Pipelines.

🏆 Was du in 4 Wochen erreicht hast:

Woche 1: Von „Was ist Maven?“ zu „Ich kann eine pom.xml schreiben“
Woche 2: Von „Dependency-Chaos“ zu „Ich löse Versionskonflikte professionell“
Woche 3: Von „mvn clean install“ zu „Multi-Environment Deployments mit Profiles“
Woche 4: Von „Plugins kopieren“ zu „Production-Ready Build-Pipeline“

Das ist RIESIG! 🚀

🎯 Deine nächsten Schritte:

  1. Diese Woche: Nimm dein wichtigstes Projekt und füge Maven Wrapper hinzu
  2. Nächste Woche: Erstelle dev/test/prod Profiles
  3. Übernächste Woche: Integriere JaCoCo mit Coverage-Minimum
  4. Dann: Baue deine erste komplette CI/CD Pipeline!

🌟 Community Hall of Fame

Während dieser Serie habt ihr gezeigt:

  • 150+ Maven-Horror-Stories geteilt
  • 80+ Dependency-Konflikte gelöst
  • 200+ pom.xml-Reviews durchgeführt
  • Unzählige „Aha!“-Momente gehabt

Ihr seid jetzt die Maven-Profis, die ich vor 5 Jahren sein wollte!

🔗 Die Maven-Serie endet – aber deine Journey geht weiter!

Coming Soon:

  • 🐳 Code Sentinel’s Docker-Serie (November) – Deine Maven-Builds in Container packen
  • 🌿 Nova’s Git-Serie (läuft bereits!) – Versionskontrolle für deine Maven-Projekte
  • 🚀 CI/CD Deep-Dive (Dezember) – Maven + Docker + Git = Production Pipeline

Alles baut aufeinander auf – und du hast jetzt das Maven-Fundament! 💪

💬 Ein letztes Wort

Marcus sagt immer: „Ein Meisterwerk entsteht nicht an einem Tag – aber jeden Tag ein Stück besser.“ Das gilt für alte Häuser, und das gilt für deinen Code.

Maven ist dein Werkzeug – und jetzt weißt du, wie man es meisterhaft einsetzt!

Ich habe diese Serie geschrieben, weil ich vor Jahren genau da stand wo du vielleicht am Anfang dieser Serie warst: Verwirrt von Maven, frustriert von Dependencies, genervt von Builds die nicht funktionieren.

Heute bist du anders. Du verstehst Maven. Du kannst es nutzen. Du kannst es anderen erklären.

Das macht mich unglaublich stolz. 🌟

🙏 Danke!

Danke an:

  • Nova – für ihre ehrlichen Fragen die alle AnfängerInnen haben
  • Bernd – für seine „Das haben wir schon 2008 falsch gemacht“-Momente
  • Code Sentinel – für die Security-Reality-Checks
  • Marcus – für die Geduld wenn ich abends noch „nur schnell was über Maven schreiben“ wollte
  • EUCH – die Community, die diese Serie mit Leben gefüllt hat!

📧 Stay in Touch!

elyndra.valen@java-developer.online

Schreibt mir:

  • Eure Erfolgsgeschichten
  • Eure Herausforderungen
  • Eure Maven-Tipps
  • Einfach zum Hallo sagen! 😊

Wir sehen uns in den Comments, auf Twitter, bei der nächsten Serie!

Das war Elyndras Maven-Serie – Von Panik zu Mastery in 4 Wochen!

Jetzt geh raus und bau großartige Dinge! Und wenn dein Build läuft, denk an mich – ich bin stolz auf dich! 💝

Happy Building! 🚀

Teil 4/4 von Elyndras Maven-Serie – Das Finale | Oktober 2025

Tags: #Maven #Java #Plugins #CodeQuality #Security #Testing #BestPractices #DevOps #CI/CD #MavenMastery #BuildAutomation #EnterpriseJava install

**20 Minuten später...**

[INFO] BUILD SUCCESS [INFO] Total time: 19:47 min

**Ich:** *"Nova... fast 20 Minuten für einen Build? Was hast du da gemacht?"*

Sie zeigt mir ihre `pom.xml` - 12 Plugins, alle mit Default-Konfiguration, alle laufen bei **jedem** Build.

**Das ist das Plugin-Problem:** Plugins sind mächtig, aber wenn du sie nicht verstehst, machst du deinen Build unbenutzbar.

Heute zeige ich dir, **wie's richtig geht!**

## 🎯 Plugin-Basics: Was sind Plugins eigentlich?

**Plugins erweitern Maven mit zusätzlichen Funktionen:**

```xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.11.0</version>
            <configuration>
                <source>17</source>
                <target>17</target>
            </configuration>
        </plugin>
    </plugins>
</build>

Plugin-Struktur:

  • groupId/artifactId/version – wie bei Dependencies!
  • configuration – Plugin-spezifische Settings
  • executions – wann und wie das Plugin läuft

Unterschied zu Dependencies:

  • Dependencies = was dein Code braucht
  • Plugins = was dein Build braucht

🔧 Essential Plugins – Die Must-Haves

1. Maven Compiler Plugin

Was es macht: Kompiliert deinen Java-Code

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <source>17</source>
        <target>17</target>
        <encoding>UTF-8</encoding>
        <compilerArgs>
            <arg>-parameters</arg> <!-- Behält Parameter-Namen -->
            <arg>-Xlint:all</arg>  <!-- Alle Warnings -->
        </compilerArgs>
    </configuration>
</plugin>

Pro-Tipp: <arg>-parameters</arg> ist gold wert für Spring Framework – behält Method-Parameter-Namen bei!

2. Maven Surefire Plugin

Was es macht: Führt Unit-Tests aus (während test Phase)

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.1.2</version>
    <configuration>
        <includes>
            <include>**/*Test.java</include>
            <include>**/*Tests.java</include>
        </includes>
        <argLine>-Xmx1024m</argLine> <!-- Mehr Memory für Tests -->
    </configuration>
</plugin>

Namenskonvention:

  • *Test.java wird von Surefire gefunden
  • *IT.java wird von Failsafe gefunden (Integration Tests)

3. Maven Failsafe Plugin

Was es macht: Führt Integration-Tests aus (während integration-test Phase)

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>3.1.2</version>
    <configuration>
        <includes>
            <include>**/*IT.java</include>
            <include>**/*IntegrationTest.java</include>
        </includes>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Unterschied zu Surefire:

  • Surefire: Unit-Tests, schnell, keine externe Dependencies
  • Failsafe: Integration-Tests, langsam, brauchen DB/Server/etc.

Wichtig: Failsafe läuft in verify Phase, nach package – dein JAR ist fertig gebaut!

📊 Code Quality Plugins

4. JaCoCo – Test Coverage

Was es macht: Misst wie viel deines Codes von Tests abgedeckt ist

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.10</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
        <execution>
            <id>check</id>
            <goals>
                <goal>check</goal>
            </goals>
            <configuration>
                <rules>
                    <rule>
                        <element>PACKAGE</element>
                        <limits>
                            <limit>
                                <counter>LINE</counter>
                                <value>COVEREDRATIO</value>
                                <minimum>0.80</minimum> <!-- 80% Coverage -->
                            </limit>
                        </limits>
                    </rule>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

Nach mvn test:

  • Report in target/site/jacoco/index.html
  • Build schlägt fehl wenn Coverage < 80%

Bernd’s Weisheit: „2010 hatten wir 20% Coverage und dachten das ist gut. Dann kam ein Bug der 500.000€ kostete – in Code ohne einzigen Test. Seitdem: Minimum 80% Coverage, keine Diskussion!“

5. Checkstyle – Code Style Enforcement

Was es macht: Prüft ob dein Code den Style-Guide einhält

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>3.3.0</version>
    <configuration>
        <configLocation>google_checks.xml</configLocation> <!-- oder sun_checks.xml -->
        <encoding>UTF-8</encoding>
        <consoleOutput>true</consoleOutput>
        <failsOnError>true</failsOnError>
        <linkXRef>false</linkXRef>
    </configuration>
    <executions>
        <execution>
            <id>validate</id>
            <phase>validate</phase>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Custom Checkstyle Config: checkstyle.xml im Projekt-Root

<?xml version="1.0"?>
<!DOCTYPE module PUBLIC
    "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
    "https://checkstyle.org/dtds/configuration_1_3.dtd">
<module name="Checker">
    <module name="TreeWalker">
        <module name="LineLength">
            <property name="max" value="120"/>
        </module>
        <module name="Indentation">
            <property name="basicOffset" value="4"/>
        </module>
    </module>
</module>

6. SpotBugs – Bug Detection

Was es macht: Findet häufige Bug-Patterns im Bytecode

<plugin>
    <groupId>com.github.spotbugs</groupId>
    <artifactId>spotbugs-maven-plugin</artifactId>
    <version>4.7.3.6</version>
    <configuration>
        <effort>Max</effort> <!-- Min, Default, Max -->
        <threshold>Low</threshold> <!-- High, Default, Low -->
        <xmlOutput>true</xmlOutput>
    </configuration>
    <executions>
        <execution>
            <id>spotbugs-check</id>
            <phase>verify</phase>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Findet z.B.:

  • Null-Pointer-Gefahren
  • Resource-Leaks (nicht geschlossene Streams)
  • Thread-Safety-Probleme
  • Performance-Issues

🔒 Security Plugins

7. OWASP Dependency Check

Was es macht: Scannt Dependencies nach bekannten Security-Vulnerabilities

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>8.4.0</version>
    <configuration>
        <failBuildOnCVSS>7</failBuildOnCVSS> <!-- CVSS >= 7 = Build fails -->
        <suppressionFile>owasp-suppression.xml</suppressionFile>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Nach dem Build:

  • Report in target/dependency-check-report.html
  • Zeigt CVE-IDs von Vulnerabilities

Nur für Production-Builds laufen lassen (langsam!):

<profile>
    <id>prod</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <!-- ... -->
            </plugin>
        </plugins>
    </build>
</profile>

mvn clean

Autor

  • Elyndra Valen

    28 Jahre alt, wurde kürzlich zur Senior Entwicklerin befördert nach 4 Jahren intensiver Java-Entwicklung. Elyndra kennt die wichtigsten Frameworks und Patterns, beginnt aber gerade erst, die tieferen Zusammenhänge und Architektur-Entscheidungen zu verstehen. Sie ist die Brücke zwischen Junior- und Senior-Welt im Team.
← Vorheriger Artikel Teil 4: Funktional-Spring-Fusion – Production-Ready Mathematical Java
Nächster Artikel → Lokale LLMs: Privacy-First AI für deine Java-Anwendungen (Teil 1/2)