22 Erweiterte Konfiguration: settings.xml, Distribution Management, Release Plugin

Maven bietet über die einfache Projektkonfiguration (pom.xml) hinaus diverse Möglichkeiten, Build- und Veröffentlichungsprozesse zu individualisieren. Die Datei settings.xml, das <distributionManagement>-Element im POM und das Maven Release Plugin sind hierfür zentrale Bausteine.

22.1 1. Erweiterte Konfiguration mit settings.xml

22.1.1 1.1 Überblick

Die Datei settings.xml im Benutzerverzeichnis (${user.home}/.m2) oder wahlweise in einem projektspezifischen Pfad enthält benutzerspezifische und globale Einstellungen, die nicht direkt in der pom.xml verankert sind. Typische Anwendungsfälle sind das Hinterlegen von Server-Authentifizierungen, Proxy-Einstellungen und Spiegelkonfigurationen.

22.1.2 1.2 Beispielinhalte

<settings>
    <!-- Lokales Repository anpassen -->
    <localRepository>/path/to/local/repo</localRepository>

    <!-- Serverkonfiguration für Deployments -->
    <servers>
        <server>
            <id>my-nexus</id>
            <username>deployUser</username>
            <password>secretPassword</password>
        </server>
    </servers>

    <!-- Proxy-Einstellungen -->
    <proxies>
        <proxy>
            <id>corp-proxy</id>
            <active>true</active>
            <protocol>http</protocol>
            <host>proxy.corporate.com</host>
            <port>8080</port>
            <username>proxyUser</username>
            <password>proxyPass</password>
            <nonProxyHosts>localhost|*.corp.com</nonProxyHosts>
        </proxy>
    </proxies>
    
    <!-- Spiegel der Repositories (z.B. eine interne Mirror-URL) -->
    <mirrors>
        <mirror>
            <id>nexus-mirror</id>
            <mirrorOf>*</mirrorOf>
            <url>http://nexus.corp.com/repository/mirror-all</url>
        </mirror>
    </mirrors>
    
    <!-- Profile mit benutzerspezifischen Settings -->
    <profiles>
        <profile>
            <id>dev-profile</id>
            <properties>
                <someCustomProperty>someValue</someCustomProperty>
            </properties>
        </profile>
    </profiles>

    <!-- Aktivierung bestimmter Profile -->
    <activeProfiles>
        <activeProfile>dev-profile</activeProfile>
    </activeProfiles>
</settings>

22.1.3 1.3 Best Practices

1. Sensiblen Umgang mit Credentials: Zugangsdaten verschlüsseln oder nur lokal verwalten (z. B. settings-security.xml).
2. Vermeidung von Projekt-spezifischen Einträgen: settings.xml sollte für Benutzer- oder Firmenweite Konfigurationen genutzt werden.
3. Spiegel und Proxy durchdacht konfigurieren: CI-Umgebungen profitieren von schnelleren Build-Zeiten, wenn häufig genutzte Artefakte lokal gespiegelt werden.

22.2 2. Distribution Management

22.2.1 2.1 Grundidee

Im <distributionManagement>-Abschnitt eines POM wird festgelegt, wohin Artefakte bei einem erfolgreichen Build (Phase deploy) veröffentlicht werden sollen. Dies umfasst sowohl Release- als auch Snapshot-Repositories.

22.2.2 2.2 Beispiel

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>

    <distributionManagement>
        <repository>
            <id>release-repo</id>
            <url>http://nexus.corp.com/repository/releases</url>
        </repository>
        <snapshotRepository>
            <id>snapshot-repo</id>
            <url>http://nexus.corp.com/repository/snapshots</url>
        </snapshotRepository>
        <site>
            <id>company-site</id>
            <url>http://webserver.corp.com/maven-sites/my-app</url>
        </site>
    </distributionManagement>
</project>

• repository: Ziel für Release-Artefakte.
• snapshotRepository: Ziel für SNAPSHOT-Versionen.
• site: Zieladresse für Maven Site-Reports.

22.2.3 2.3 Authentifizierung

Die in <distributionManagement> verwendeten <id>-Angaben müssen in der settings.xml unter <servers> hinterlegt sein, damit Maven die nötigen Credentials kennt.

22.2.4 2.4 Best Practices

1. Trennung von Snapshot und Release: Verhindert unbeabsichtigte Bereitstellung unausgereifter Artefakte.
2. Eindeutige IDs: Vermeidet Verwechslungen, wenn mehrere Repositories angebunden sind (z. B. interne und externe).
3. Nur Release-Artefakte: In Produktivumgebungen sollte man möglichst keine SNAPSHOT-Versionen verwenden.

22.3 3. Maven Release Plugin

22.3.1 3.1 Grundidee

Das Release Plugin automatisiert den Prozess der Versionsanpassung, Tag-Erzeugung im Versionskontrollsystem und das Verteilen der Artefakte in ein Remote-Repository. So wird sichergestellt, dass Releases reproduzierbar und einheitlich durchgeführt werden.

22.3.2 3.2 Ablauf eines Releases

1. Prepare
   • Wechselt von SNAPSHOT-Version (z. B. 1.0.0-SNAPSHOT) auf eine Release-Version (z. B. 1.0.0).
   • Commit & Tag (release-1.0.0) im SCM.
   • Setzt anschließend die nächste SNAPSHOT-Version (z. B. 1.0.1-SNAPSHOT).
2. Perform
   • Baut das Projekt aus dem Tag heraus.
   • Führt Tests durch.
   • Deployt fertige Artefakte in das Release-Repository.

22.3.3 3.3 Typische Konfiguration im POM

<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, z.B. für GIT oder SVN -->
    </configuration>
</plugin>

• autoVersionSubmodules: Passt die Versionsnummern aller Module in einem Multi-Module-Projekt an.
• pushChanges: Wenn true, werden Änderungen direkt in die Remote-Versionsverwaltung übertragen.

22.3.4 3.4 Release durchführen

# Vorbereitung und Versionsanpassung
mvn release:prepare
# Erzeugt Tag, ändert POM auf Release-Version, committet, setzt nächste SNAPSHOT-Version
# Deployment und finaler Release
mvn release:perform

22.3.5 3.5 Häufige Stolpersteine

• Uncommitted Changes: Plugin verweigert den Prozess, wenn lokale Änderungen nicht eingecheckt sind.
• Credentials: Auch hier muss <id> im <distributionManagement> mit settings.xml übereinstimmen.
• Multi-Module: Alle Module müssen synchronisiert sein, unterschiedliche Versionsschemata benötigen manuelle Anpassungen.

22.4 4. Zusammenspiel in der Praxis

1. Lokale Einstellungen: In settings.xml werden private Repositories, Spiegel und Servercredentials definiert.
2. Veröffentlichungskonfiguration: Im POM (<distributionManagement>) steht, wohin Snapshots und Releases kommen.
3. Release-Vorgehen: Mit dem Release Plugin wird der Build automatisiert, Versionen hochgezogen und Artefakte sauber in das angegebene Repository deployt.

Ziel ist es, dass jede auslieferbare Version klar mit einem Tag im SCM verknüpft ist und dass sich auf einfache Weise nachvollziehen lässt, woher Artefakte stammen. Alle involvierten Entwickler und CI/CD-Umgebungen greifen auf dieselbe Konfiguration zu, was den gesamten Prozess standardisiert und reproduzierbar macht.

22.5 5. Best Practices und Zusammenfassung

• settings.xml sauber halten: Nur Benutzer- oder unternehmensweite Einstellungen. Keine projektspezifischen Infos wie spezielle Dependencies.
• Distribution Management klar trennen: Verschiedene Repositories für SNAPSHOT und Releases helfen, Verwechslungen zu vermeiden.
• Release Plugin früh einrichten: Je früher das Team an einen standardisierten Release-Prozess gewöhnt wird, desto weniger manuelle Fehler treten im Projektverlauf auf.
• CI/CD-Einbindung: Insbesondere das Release Plugin verlangt gültige Credentials und saubere Versionsverwaltung (z. B. Jenkins, GitLab CI oder GitHub Actions).

Mit der erweiterten Konfiguration durch settings.xml, Distribution Management und das Maven Release Plugin lassen sich Maven-Projekte standardisiert, sicher und effizient veröffentlichen. Diese Bausteine stellen sicher, dass Ihre Builds konsistent, die Artefakte klar versioniert und die Credentials an zentraler Stelle verwaltet sind. So wird ein reibungsloser Entwicklungs- und Auslieferungsprozess gewährleistet.