asv-format-validator/docs/arbeitspakete/m1/AP06-bootstrap-cli.md

AP06 – Bootstrap und CLI-Adapter

Ziel

Die bestehende AsvValidatorApplication wird in zwei klar getrennte Verantwortlichkeiten zerlegt:

1. Bootstrap (de.gecheckt.asv.bootstrap.Main) — verdrahtet die Komponenten manuell per Constructor Injection und ist der einzige public static void main.
2. CLI-Adapter (de.gecheckt.asv.adapter.in.cli.CliRunner oder ähnlich) — nimmt CLI-Argumente entgegen, ruft die Application-Schicht auf, übersetzt das Ergebnis in einen Exit-Code.

Zusätzlich werden die Exit-Codes spec-konform auf 0/1/2 umgestellt.

Voraussetzungen

• AP03, AP04, AP05

Scope IN

Bootstrap

• Klasse de.gecheckt.asv.bootstrap.Main mit public static void main(String[] args)
• verdrahtet manuell:
  • Logging-Konfigurator
  • CLI-Runner
  • (Application-Service — Platzhalter, wird in AP09 feingeschnitten)
• ruft CliRunner.run(args) auf, gibt den zurückgegebenen Exit-Code an System.exit weiter

CLI-Adapter

• Klasse CliRunner im Paket adapter.in.cli
• Methode int run(String[] args)
• akzeptiert genau ein Positionsargument: den Pfad zur Eingabedatei
• bei 0 oder ≥2 Argumenten → Exit-Code 2, Minimalbericht-Vorbereitung (vollständige Minimalbericht-Logik kommt in AP08)
• bei nicht existierender, nicht lesbarer oder nicht regulärer Eingabedatei → Exit-Code 2
• bei erfolgreichem Lauf ohne Spec-Fehler → Exit-Code 0
• bei erfolgreichem Lauf mit Spec-Fehlern → Exit-Code 1

Exit-Code-Konstanten

• Konstanten nur noch in einer Klasse (z.B. ExitCode im Paket adapter.in.cli)
• Werte:
  • 0 = gültig, keine Fehler-Befunde
  • 1 = ungültig, mindestens ein Spec-Fehler
  • 2 = Bedienfehler
• Die alten Konstanten (EXIT_CODE_INVALID_ARGUMENTS=1, EXIT_CODE_FILE_ERROR=2, EXIT_CODE_VALIDATION_ERRORS=3) werden gelöscht

Verdrahtung mit Befundmodell (AP05)

• CliRunner gibt am Ende einen ValidationReport aus AP05 weiter oder erzeugt selbst einen Minimal-ValidationReport mit einem Finding des Kinds SPEC, Severity ERROR, Layer ARTIFACT im Bedienfehlerfall
• das eigentliche Einlesen und Verarbeiten der Datei kann für M1 noch ein Dummy-Pfad sein: die Datei wird gelesen, die Bytes gezählt, ein leerer ValidationReport mit fileName und timestamp zurückgegeben. Echte Validierung gehört nicht in M1.

Zeichensatz-Korrektur

• beim Einlesen der Eingabedatei wird ISO 8859-15 verwendet, nicht UTF-8. Das ist eine harte Spec-Vorgabe aus fachliche-anforderungen.md §5.1 und muss ab jetzt dauerhaft so bleiben.

  Files.readString(path, StandardCharsets.ISO_8859_1);  // nicht ideal — besser Charset.forName("ISO-8859-15")
  

  Achtung: Java kennt StandardCharsets.ISO_8859_1, aber nicht ISO_8859_15. Daher Charset.forName("ISO-8859-15") verwenden.

Scope OUT

• Berichtdatei und Log-Datei im Eingabeverzeichnis (AP07)
• vollständiger Minimalbericht bei Exit-Code 2 (AP08)
• Entkopplung der Altlogik (AP09)
• Architekturtest (AP10)

Schritte

1. Branch m1/ap06-bootstrap-cli
2. de.gecheckt.asv.bootstrap.Main anlegen mit public static void main
3. CliRunner in adapter.in.cli anlegen
4. ExitCode-Konstantenklasse anlegen
5. AsvValidatorApplication schrittweise entkernen: Code wandert nach CliRunner und Main
6. Einlese-Encoding auf Charset.forName("ISO-8859-15") umstellen
7. maven-jar-plugin in pom.xml auf de.gecheckt.asv.bootstrap.Main setzen (Platzhalter aus AP02 konkretisieren)
8. Alle Tests, die auf AsvValidatorApplication direkt zeigen, auf CliRunner umziehen
9. mvn clean package laufen lassen, das erzeugte JAR manuell mit java -jar target/asv-format-validator-*.jar <test-datei> prüfen
10. mvn clean verify grün bekommen
11. Commit M1-AP06: Bootstrap, CLI-Adapter, Exit-Codes 0/1/2, ISO 8859-15
12. Abschlussbericht schreiben

Abnahmekriterien

• de.gecheckt.asv.bootstrap.Main existiert und ist Main-Class des JAR
• CliRunner ist der einzige Ort mit CLI-Argument-Parsing
• Exit-Codes 0, 1, 2 sind definiert und spec-konform eingesetzt
• Test: Aufruf ohne Argument → Exit-Code 2
• Test: Aufruf mit nicht existierender Datei → Exit-Code 2
• Test: Aufruf mit leerer, lesbarer Datei → Exit-Code 0 (Dummy-Pfad, leerer ValidationReport)
• Einlese-Encoding ist ISO 8859-15 (per Test belegt: eine Datei mit Byte 0xA4 ergibt beim Einlesen €, weil 0xA4 in ISO 8859-15 auf Euro-Zeichen liegt)
• ausführbares JAR unter target/ ist manuell startbar
• mvn clean verify ist grün
• Abschlussbericht liegt vor

Rest-Risiken und offene Punkte

• Der Dummy-Pfad (Datei wird gelesen, leerer Report zurückgegeben) ist bewusst dünn. Die Einbindung der alten Parser-Logik passiert in AP09.
• Es ist verlockend, schon hier in AP06 die bestehende Parser-/Validator-Kette mit dem neuen Modell zu verknüpfen. Nicht tun. AP06 soll nur die äußere Hülle geradeziehen.

Bericht

docs/arbeitspakete/m1/berichte/AP06-bericht.md nach templates/ap-bericht.md.