10 Plugins im Detail (Failsafe, Enforcer, Shade, Release)

Maven-Plugins erweitern die Funktionalität des Build-Prozesses und sind ein wesentlicher Bestandteil, um komplexe Projekte effizient und standardisiert zu bauen. In diesem Kapitel vertiefen wir uns in vier besonders wichtige und interessante Plugins: Failsafe, Enforcer, Shade und Release. Jedes dieser Plugins adressiert unterschiedliche Aspekte des Build-Prozesses – von Integrationstests über Richtliniendurchsetzung, Erstellen ausführbarer Archive bis hin zum automatisierten Release-Management.

10.1 Maven Failsafe Plugin

10.1.1 Überblick

Das Maven Failsafe Plugin ist ein Ergänzungsplugin zum Surefire Plugin und wird für Integrationstests verwendet. Während das Surefire Plugin hauptsächlich Unit-Tests in der Phase test ausführt, kommt Failsafe in den Phasen integration-test und verify zum Einsatz. So können komplexe Tests (z.B. gegen eine Datenbank oder ein externes System) separat vom regulären Kompilier- und Testzyklus laufen.

10.1.2 Typische Konfiguration

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>3.0.0-M7</version>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

• integration-test: Führt die eigentlichen Integrationstests aus.
• verify: Verifiziert die Ergebnisse und schlägt fehl, wenn eine Integrationstestklasse fehlschlägt.

10.1.3 Best Practices

1. Trennung von Unit-Tests und Integrationstests
   • Unit-Tests: mvn test (Surefire)
   • Integrationstests: mvn verify (Failsafe)
2. Benennungsschema
   • Unit-Test-Klassen: *Test.java
   • Integrationstest-Klassen: *IT.java oder *ITCase.java, damit Failsafe sie automatisch erkennt.
3. Kontrollierter Aufbau der Testumgebung
   • Datenbank initialisieren, Container starten, externe Services stubs/fakes etc.

10.2 Maven Enforcer Plugin

10.2.1 Überblick

Das Maven Enforcer Plugin setzt Richtlinien und Standards in einem Maven-Projekt durch. Es kann beispielsweise sicherstellen, dass eine bestimmte Java-Version genutzt wird, dass keine verbotenen Abhängigkeiten im Projekt sind oder dass die Maven-Version den Projektanforderungen entspricht.

10.2.2 Typische Konfiguration

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <id>enforce-rules</id>
            <goals>
                <goal>enforce</goal>
            </goals>
            <configuration>
                <rules>
                    <requireMavenVersion>
                        <version>[3.6,)</version>
                    </requireMavenVersion>
                    <requireJavaVersion>
                        <version>[11,)</version>
                    </requireJavaVersion>
                    <banDuplicatePomDependencyVersions/>
                </rules>
                <failFast>true</failFast>
            </configuration>
        </execution>
    </executions>
</plugin>

• requireMavenVersion: Stellt sicher, dass mindestens Maven 3.6 verwendet wird.
• requireJavaVersion: Stellt sicher, dass mindestens Java 11 installiert ist.
• banDuplicatePomDependencyVersions: Verhindert doppelte Versionseinträge.

10.2.3 Anwendungsbeispiele

• Unternehmenskonforme Builds: Einheitliche Java-Version, verbotene Libraries (z.B. veraltete Log4j-Versionen), striktes Versionierungsschema.
• Multi-Module-Setups: Sicherstellen, dass in den Submodulen keine ungewollten Versionen verwendet werden.

10.2.4 Best Practices

1. Frühzeitiges Ausführen: Das Enforcer-Plugin am besten in einer frühen Phase (z.B. validate) laufen lassen.
2. Klare Regeln: Regeln sollten dokumentiert sein. Entwickler sollen wissen, warum bestimmte Abhängigkeiten verboten sind oder eine bestimmte Java-Version erforderlich ist.

10.3 Maven Shade Plugin

10.3.1 Überblick

Das Maven Shade Plugin erlaubt das Erstellen sogenannter „Fat-JARs“ oder „Uber-JARs“. Dabei werden alle Abhängigkeiten (Libraries) in ein einziges ausführbares Archiv gepackt. Dies ist nützlich für: - CLI-Tools oder Microservices, die nur eine einzige ausführbare JAR benötigen. - Inkompatible Class-Path-Konflikte: Durch relocation kann man Paketnamen verschieben, um Klassennamenkollisionen zu vermeiden.

10.3.2 Typische Konfiguration

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.4</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <createDependencyReducedPom>true</createDependencyReducedPom>
                <relocations>
                    <relocation>
                        <pattern>org.conflicting.lib</pattern>
                        <shadedPattern>my.project.shaded.org.conflicting.lib</shadedPattern>
                    </relocation>
                </relocations>
            </configuration>
        </execution>
    </executions>
</plugin>

• dependencyReducedPom: Erzeugt eine POM, die keine bereits „geshadeten“ Abhängigkeiten mehr auflistet.
• relocation: Ein Beispiel, wie Namenskollisionen durch Umbenennung vermieden werden können.

10.3.3 Einsatzmöglichkeiten

1. Serverless-Umgebungen: AWS Lambda oder ähnliche Services benötigen oftmals ein einzelnes Archiv, das alle Abhängigkeiten enthält.
2. Transport von Tools: CLI-Anwendungen, die auf beliebigen Systemen lauffähig sein sollen, ohne dass externe JARs installiert werden müssen.
3. Beseitigung von Konflikten: Zwei Abhängigkeiten verwenden dieselbe Klasse mit unterschiedlichen Implementierungen.

10.3.4 Best Practices

• Achtung bei Spring Boot: Spring Boot hat seinen eigenen Weg, Fat-JARs zu erzeugen (Spring Boot Maven Plugin). Shade kann dort zu Komplikationen führen.
• Sparsame Relocation: Nur einsetzen, wenn unbedingt nötig.
• Testen: Umbennenungen sorgfältig prüfen, da Reflection-basierte Zugriffe fehlschlagen könnten.

10.4 Maven Release Plugin

10.4.1 Überblick

Das Maven Release Plugin unterstützt den kompletten Release-Prozess eines Projekts: Versionsnummern anpassen, Quellcode taggen, Artefakte bauen, ins Repository deployen und die nächste SNAPSHOT-Version einstellen. Dadurch wird der Vorgang, der früher manuell und fehleranfällig war, automatisiert und reproduzierbar.

10.4.2 Release Workflow

1. prepare:
   • Prüft, ob der lokale Code „clean“ ist (kein uncommitter Code).
   • Ändert die Versionsnummer auf eine Release-Version (z.B. von 1.0.0-SNAPSHOT zu 1.0.0).
   • Commit und Tag im Versionsverwaltungssystem (Git, Subversion etc.).
   • Setzt die Versionsnummer anschließend auf die nächste SNAPSHOT-Version (z.B. 1.0.1-SNAPSHOT).
2. perform:
   • Checkt den Tag aus, kompiliert und testet.
   • Deployt die fertigen Artefakte ins Remote-Repository.

10.4.3 Typische Konfiguration

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>3.0.0-M1</version>
    <configuration>
        <autoVersionSubmodules>true</autoVersionSubmodules>
        <pushChanges>true</pushChanges>
        <!-- Weitere Einstellungen wie GIT- oder SVN-Details -->
    </configuration>
</plugin>

• autoVersionSubmodules: Setzt Versionsnummern aller Submodule automatisch.
• pushChanges: Legt fest, ob die Änderungen und Tags automatisch in die zentrale Versionsverwaltung gepusht werden.

10.4.4 Praxis und Stolpersteine

1. Zugangsdaten: In der settings.xml müssen u.U. Credentials für SCM und das Deployment-Repository hinterlegt sein.
2. Passende Versionspolitik: Projekt muss klären, wann eine Version z.B. 1.0.0, 1.1.0 oder 2.0.0 lautet (SemVer oder ähnliches).
3. Multi-Module: Im Multi-Module-Kontext kann es komplexer sein, wenn Submodule unterschiedliche Versionsnummern haben sollen.
4. Testing: Vor einem Release sollte der Build bei CI-Servern (Jenkins, GitLab, GitHub Actions) immer erfolgreich durchlaufen, um Überraschungen beim Release zu vermeiden.

10.5 Zusammenfassung

• Failsafe Plugin: Ergänzt Surefire um Integrationstests in den Phasen integration-test und verify.
• Enforcer Plugin: Erzwingt Richtlinien, um im Team einheitliche Java-Versionen und Bibliotheken zu nutzen.
• Shade Plugin: Erstellt Fat-JARs, kombiniert alle Abhängigkeiten und vermeidet Classpath-Konflikte.
• Release Plugin: Automatisiert den Release-Prozess inklusive Tagging, Versionsanpassung und Deployment.

Mit diesen vier Plugins deckt Maven zentrale Aspekte der Softwareentwicklung ab: saubere Trennung von Unit- und Integrationstests, Einhaltung von Standards, Erzeugung ausführbarer Archive und reibungsloses Versionsmanagement. Ein tiefes Verständnis dieser Plugins macht den Entwicklungsprozess effizienter, sicherer und besser reproduzierbar.