Maven Enterprise Lernpfad

Ziel: Dieser Lernpfad führt dich Schritt für Schritt von Maven-Grundlagen bis zu komplexen Enterprise-Multi-Module-Builds. Er ist mit den Beispielprojekten in diesem Paket verknüpft.

So nutzt du das Paket:

1. Starte mit diesem Lernpfad.
2. Öffne danach das POM-Beispielbuch unter docs/maven-pom-beispielbuch.html.
3. Analysiere die Projekte in projects/.
4. Baue einzelne Module lokal mit Maven nach.
5. Vergleiche Spring-Boot-Microservices und Jakarta-EE-WAR-Deployments.

1. Orientierung: Was Maven in Enterprise-Projekten leistet

Maven ist in Enterprise-Java-Projekten mehr als ein Build-Tool. Es definiert technische Standards für Module, Dependencies, Plugins, Tests, Releases und Deployment.

Du solltest Maven als vier Dinge verstehen:

• Projektmodell: Koordinaten, Packaging, Module, Parent-Beziehungen.
• Dependency-System: transitive Dependencies, Scopes, BOMs und Version Management.
• Build-Orchestrator: Lifecycle-Phasen, Plugins und Goals.
• Governance-Werkzeug: Enforcer-Regeln, Security-Vorgaben, Repository-Strategien und reproduzierbare Builds.

Lernziel

Du kannst erklären, warum eine große Organisation oft eine Parent-POM, eine BOM und mehrere Modul-POMs trennt.

Übung

Öffne:

projects/enterprise-maven-beispiele/acme-platform/

Suche dort nach:

acme-platform-bom
acme-build-parent

Erkläre den Unterschied zwischen beiden Modulen.

2. Maven-Koordinaten und Packaging

Jedes Maven-Artefakt wird über Koordinaten identifiziert:

<groupId>com.acme.platform</groupId>
<artifactId>customer-service</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>jar</packaging>

Wichtige Packaging-Typen:

Lernziel

Du erkennst, ob eine POM selbst ein Artefakt erzeugt oder hauptsächlich andere Module steuert.

Übung

Vergleiche diese Root-POMs:

projects/enterprise-commerce-platform/pom.xml
projects/jakarta-retail-banking-platform/pom.xml
projects/enterprise-maven-beispiele/acme-order-service/pom.xml

Achte auf packaging, modules und dependencyManagement.

3. Parent-POM, Aggregator-POM und BOM sauber trennen

In einfachen Projekten kann eine POM alles gleichzeitig sein. In Enterprise-Projekten trennt man Rollen häufiger klarer.

Parent-POM

Eine Parent-POM vererbt Standards an Child-Module:

<parent>
    <groupId>com.acme.platform</groupId>
    <artifactId>acme-build-parent</artifactId>
    <version>1.0.0</version>
</parent>

Typische Inhalte:

• Java-Version
• Plugin-Versionen
• Enforcer-Regeln
• Test- und Report-Konfiguration
• Compiler- und Encoding-Standards

Aggregator-POM

Eine Aggregator-POM baut Module gemeinsam:

<modules>
    <module>customer-service</module>
    <module>order-service</module>
    <module>payment-service</module>
</modules>

BOM

Eine BOM verwaltet Dependency-Versionen zentral:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring.boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Merksatz

Parent vererbt Build-Regeln. Aggregator baut Module. BOM kontrolliert Dependency-Versionen.

4. Dependency Management verstehen

dependencyManagement fügt keine Dependency automatisch hinzu. Es legt nur Versionen, Scopes oder Ausschlüsse zentral fest.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.testcontainers</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${testcontainers.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Ein Modul aktiviert sie anschließend ohne eigene Version:

<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>junit-jupiter</artifactId>
</dependency>

Typische Enterprise-Regeln

• Versionsnummern möglichst nicht in Child-POMs verteilen.
• Spring-/Quarkus-/Jakarta-BOMs importieren statt Einzelversionen pflegen.
• Security-relevante Overrides bewusst dokumentieren.
• Transitive Dependencies regelmäßig prüfen.

Übung

Öffne:

projects/enterprise-commerce-platform/pom.xml

Suche nach:

<dependencyManagement>

Beantworte:

1. Welche BOMs werden importiert?
2. Welche internen Module werden versioniert?
3. Welche Dependencies tauchen später in Service-POMs ohne Version auf?

5. Dependency Scopes

Maven-Scopes steuern, wann eine Dependency verfügbar ist.

Jakarta-EE-Hinweis

In Jakarta-EE-WAR-Projekten ist die Jakarta-EE-API meistens provided, weil der Application Server die Implementierung bereitstellt.

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <scope>provided</scope>
</dependency>

Spring-Boot-Hinweis

Spring-Boot-Services bringen ihre Runtime typischerweise selbst mit und werden als ausführbare JARs gebaut.

6. Maven Lifecycle und Plugin-Ausführung

Maven arbeitet mit Lifecycle-Phasen. Plugins hängen Goals an diese Phasen.

Beispiel:

mvn clean verify

Dieser Befehl führt alle Phasen bis verify aus. In Enterprise-Projekten hängen daran oft Tests, JaCoCo, Enforcer, Checkstyle und Integrationstests.

7. Plugin Management vs. Plugins

pluginManagement definiert Versionen und Standardkonfigurationen, führt Plugins aber nicht automatisch aus.

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>${maven.compiler.plugin.version}</version>
        </plugin>
    </plugins>
</pluginManagement>

Aktiv wird ein Plugin in build/plugins:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Übung

Öffne:

projects/enterprise-maven-beispiele/acme-quality-parent/pom.xml

Ermittle:

• Welche Plugins sind nur verwaltet?
• Welche Plugins werden tatsächlich ausgeführt?
• Welche Phasen sind gebunden?

8. Qualitäts-Gates im Build

Enterprise-Builds sollen Fehler früh sichtbar machen. Typische Maven-Quality-Gates:

• maven-enforcer-plugin: Java-Version, Maven-Version, Dependency-Regeln.
• maven-surefire-plugin: Unit Tests.
• maven-failsafe-plugin: Integrationstests.
• jacoco-maven-plugin: Coverage.
• maven-checkstyle-plugin: Format- und Stilregeln.
• spotbugs-maven-plugin: statische Fehleranalyse.
• versions-maven-plugin: Dependency-Updates prüfen.

Beispielstrategie

mvn -U clean verify

Für Pull Requests:

mvn clean verify -Pci

Für Releases:

mvn clean deploy -Prelease

9. Multi-Module Reactor

Der Maven Reactor baut Module in der richtigen Reihenfolge.

root-pom
├── shared-kernel
├── event-contracts
├── customer-service
├── order-service
└── notification-service

Wenn order-service von event-contracts abhängt, baut Maven zuerst event-contracts.

Nützliche Befehle:

# Nur ein Modul und seine Abhängigkeiten bauen
mvn -pl services/order-service -am clean verify

# Ab einem Modul weiterbauen
mvn -rf :order-service verify

# Tests überspringen, aber Testcode nicht kompilieren
mvn clean package -DskipTests

# Tests und Testkompilierung komplett überspringen
mvn clean package -Dmaven.test.skip=true

Übung

Nutze das Spring-Microservices-Beispiel:

projects/enterprise-commerce-platform/

Finde heraus, welche Libraries vor den Services gebaut werden müssen.

10. Profiles richtig einsetzen

Profiles sind nützlich, aber sie können Builds schwer nachvollziehbar machen.

Typische Profile:

<profiles>
    <profile>
        <id>ci</id>
        <properties>
            <skip.integration.tests>false</skip.integration.tests>
        </properties>
    </profile>
    <profile>
        <id>release</id>
        <properties>
            <docker.push>true</docker.push>
        </properties>
    </profile>
</profiles>

Gute Regeln

• Profile für Umgebung und Build-Modus verwenden, nicht für Fachlogik.
• Default-Build lokal einfach halten.
• CI-Profile dokumentieren.
• Unterschiede zwischen dev, test, prod nicht nur in Maven verstecken.

11. Spring Boot mit Maven

Spring Boot nutzt typischerweise:

• Spring Boot Parent oder Spring Boot BOM
• spring-boot-maven-plugin
• ausführbare JARs
• optional Container Image Build

Beispiel:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

Im Paket findest du ein größeres Spring-Boot-Microservices-Beispiel:

projects/enterprise-commerce-platform/

Wichtige Module:

libs/shared-kernel
libs/event-contracts
services/customer-service
services/catalog-service
services/order-service
services/payment-service
services/notification-service
services/api-gateway

Lernziel

Du verstehst, warum Shared Libraries, Event Contracts und Service-POMs getrennt sind.

12. Jakarta EE mit Maven

Jakarta-EE-Projekte bauen häufig WAR-Dateien für einen Application Server.

Typische Struktur:

jakarta-retail-banking-platform/
├── domain-kernel/
├── api-contracts/
├── customer-app/
├── account-app/
├── transfer-app/
└── notification-app/

Wichtig ist der Scope provided für Jakarta APIs:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <scope>provided</scope>
</dependency>

Lernziel

Du erkennst den Unterschied zwischen selbstlaufendem Spring-Boot-JAR und Jakarta-EE-WAR für einen Application Server.

13. Repositories, Distribution Management und CI/CD

Enterprise-Projekte nutzen selten direkt nur Maven Central. Häufig gibt es interne Repository Manager wie Nexus oder Artifactory.

Typische POM-Abschnitte:

<distributionManagement>
    <repository>
        <id>company-releases</id>
        <url>https://repo.example.com/releases</url>
    </repository>
    <snapshotRepository>
        <id>company-snapshots</id>
        <url>https://repo.example.com/snapshots</url>
    </snapshotRepository>
</distributionManagement>

Credentials gehören nicht in die POM, sondern in settings.xml oder in CI-Secrets.

14. Release- und Versionierungsstrategie

Häufige Strategien:

Für Lernzwecke ist eine gemeinsame Version einfacher. Für große Plattformen ist eine BOM-Strategie oft sauberer.

15. Troubleshooting

Dependency-Konflikte analysieren

mvn dependency:tree
mvn dependency:tree -Dincludes=org.slf4j

Effektive POM anzeigen

mvn help:effective-pom

Effektive Settings anzeigen

mvn help:effective-settings

Warum wird ein Plugin ausgeführt?

mvn -X clean verify

Typische Probleme

16. Empfohlene Lernreihenfolge mit diesem Paket

Woche 1: Maven-Grundlagen

• docs/maven-lernpfad.html
• docs/maven-pom-beispielbuch.html
• Projekt: projects/enterprise-maven-beispiele/acme-quality-parent/

Woche 2: Multi-Module und Dependency Management

• Projekt: projects/enterprise-maven-beispiele/acme-platform/
• Projekt: projects/enterprise-maven-beispiele/acme-order-service/

Woche 3: Spring-Boot-Microservices mit Maven

• Lernbuch: docs/spring-jakarta-enterprise-microservices.html
• Projekt: projects/enterprise-commerce-platform/

Woche 4: Jakarta EE mit Maven

• Lernbuch: docs/jakarta-ee-schwerpunkt-beispiel.html
• Projekt: projects/jakarta-retail-banking-platform/

Woche 5: CI/CD, Quality Gates und Deployment

• Enforcer, JaCoCo, Surefire, Failsafe prüfen.
• docker-compose.yml und Deployment-Ordner lesen.
• Eigene Profile ci und release ergänzen.

17. Abschlussaufgabe

Erstelle eine eigene neue Plattform-POM:

my-enterprise-platform/
├── pom.xml
├── my-platform-bom/
├── my-build-parent/
├── my-shared-kernel/
└── my-demo-service/

Pflichtanforderungen:

• Java-Version zentral als Property.
• Dependency-Versionen nur in BOM oder Parent.
• Compiler, Surefire, Failsafe und Enforcer zentral konfigurieren.
• Ein Unit Test und ein Integrationstest.
• Ein ci-Profile.
• Kurze README.md mit Build-Kommandos.

18. Nächster Schritt

Öffne die zentrale Startseite:

index.html

Von dort erreichst du alle Dokumente und Beispielprojekte an einem Ort.

19. Zusätzliche SVG-Diagramme und Lernhilfen

Dieses Kapitel ergänzt den Lernpfad um weitere visuelle Lernhilfen. Die Diagramme sind so aufgebaut, dass du sie als Wiederholung, Workshop-Folien oder Checkliste verwenden kannst.

19.1 Lernpfad als Stufenmodell

Beschreibung:
Beginne mit Koordinaten und Lifecycle. Danach lernst du Dependencies und BOMs. Anschließend verstehst du Plugins und Multi-Module-Builds. Am Ende geht es um CI/CD, Releases und Governance.

Lernkontrolle:
Du bist auf Enterprise-Niveau, wenn du eine unbekannte Parent-POM lesen, die Effective POM erklären und einen fehlgeschlagenen CI-Build systematisch analysieren kannst.

19.2 Maven-Befehle als Entscheidungslandkarte

Beschreibung:
Nicht jeder Build braucht clean install. Für Analyse nutzt du help:effective-pom oder dependency:tree. Für Pull Requests ist meistens mvn clean verify besser geeignet. Für einzelne Module nutzt du -pl und -am.

Übung:

mvn help:effective-pom
mvn dependency:tree
mvn -pl services/order-service -am clean verify

19.3 Dependency Scopes und Classpath

Beschreibung:
compile ist der Standard. provided ist besonders wichtig für Jakarta EE, weil der Application Server APIs und Implementierungen bereitstellt. test bleibt außerhalb des produktiven Artefakts.

Merksatz:
Spring-Boot-JARs bringen viel Runtime selbst mit. Jakarta-EE-WARs verlassen sich stärker auf den Application Server.

19.4 Repository und lokaler Cache

Beschreibung:
Der lokale Cache unter ~/.m2/repository beschleunigt Builds. In Unternehmen sollte settings.xml meist auf einen Repository Manager wie Nexus oder Artifactory zeigen, damit Builds reproduzierbarer und kontrollierbarer sind.

Typische Analysebefehle:

mvn help:effective-settings
mvn -U clean verify

19.5 Spring-Boot-JAR vs. Jakarta-EE-WAR

Beschreibung:
Ein Spring-Boot-Service wird häufig als ausführbares JAR gebaut und in Container/Kubernetes betrieben. Eine Jakarta-EE-Anwendung wird häufig als WAR gebaut und auf einem Application Server bereitgestellt.

Vergleich im Paket:

projects/enterprise-commerce-platform/
projects/jakarta-retail-banking-platform/

19.6 Troubleshooting als Lernmethode

Beschreibung:
Wenn ein Build fehlschlägt, ordne zuerst ein: Dependency, Plugin, Test oder Umgebung. Danach wählst du den passenden Befehl. So vermeidest du blindes Ändern an POM-Dateien.

Mini-Checkliste:

1. Fehlermeldung vollständig lesen.
2. Mit help:effective-pom prüfen, welche Konfiguration wirklich gilt.
3. Mit dependency:tree Abhängigkeitskonflikte prüfen.
4. Mit -X nur dann debuggen, wenn normale Logs nicht reichen.