PROCUREX · Statische HTML-Dokumentation

Maven-Build-Performance und Testausführung

Aus docs\build-performance.md konvertiert – vollständig lokal lesbar.

Maven-Build-Performance und Testausführung

Befund

Der ursprüngliche Aufruf mvn test war auf dem lokalen Windows-Rechner ungewöhnlich langsam.

Er lief aber erfolgreich durch: 156,7 Sekunden, mit grünen Unit- und Contract-Tests.

Die Messung wurde mit Maven 3.9.16, JDK 21.0.11 und warmem lokalem Maven-Repository am

10.08.2026 durchgeführt. Das Projekt kompiliert weiterhin mit Java 17 (maven.compiler.release=17);

die lokale Maven-JVM war lediglich JDK 21.

Ursache

Der Reactor enthält elf Maven-Projekte. Ohne Parallelisierung werden unabhängige Module und ihre

jeweiligen Surefire-Läufe nacheinander verarbeitet. Jeder Modul-Testlauf bringt außerdem

Initialisierungs- und JVM-Agent-Overhead mit. Die Spring-Cloud-Contract-Generierung war im

Messlauf dagegen bereits aktuell und nicht der Hauptverursacher.

Die Testcontainers-Integrationstests sind kein Grund für die lange Standardmessung, weil sie in

procurex-app/pom.xml standardmäßig ausgeschlossen sind. Sie brauchen eine eigene Docker-Engine

und werden separat ausgeführt.

Maßnahme

Im Projekt liegt .mvn/maven.config mit:

-B
-ntp
-T 1C

Damit laufen unabhängige Module parallel, Maven arbeitet nicht-interaktiv und erzeugt weniger

Terminalrauschen. Der parallele Lauf wurde erfolgreich verifiziert:

Messung Zeit Ergebnis
mvn test vor der Maßnahme 156,7 s BUILD SUCCESS
mvn -T 1C test nach der Maßnahme 106,2 s BUILD SUCCESS

Das entspricht in dieser lokalen Umgebung einer Reduktion um rund 32 %. Die Werte sind keine

garantierte SLA, weil CPU, Dateisystem, JDK und Maven-Cache die Laufzeit beeinflussen.

Bewusste Grenze

Die parallele Reactor-Ausführung gibt für das nicht als thread-safe markierte Spring-Cloud-

Contract-Plugin eine Maven-Warnung aus. Im aktuellen Build liegt procurex-app am Ende der

Modulabhängigkeiten; die Verifikation war grün. Bei Änderungen am Reactor oder Contract-Plugin

muss die Parallelisierung erneut geprüft werden.

Die drei Testcontainers-Tests bleiben ein separates Gate:

mvn test -Dtest=ApprovalConcurrencyIntegrationTest
mvn test -Dtest=ProcureToPayFlowIntegrationTest
mvn test -Dtest=UniqueConstraintIntegrationTest

Ein grüner Standardlauf beweist daher nicht automatisch die Datenbankintegration.

⌂ Cockpit