97 lines
4.9 KiB
Markdown
97 lines
4.9 KiB
Markdown
# 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.
|
||
```java
|
||
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`.
|