Drei Stränge, die sich über dieselben Dateien ziehen (HomePage, index.css,
README, application.properties) und deshalb nicht getrennt committet werden
können, ohne einen nicht übersetzbaren Zwischenstand zu hinterlassen:
Adressdaten: Der Bereich zeigt den gesamten Bestand des globalen Telefon-
buchs - zuerst aus dem Adress-Cache der App (Protokoll 8), sonst über das
Kommando "addresses" und ersatzweise aus rund 110 Einzelabfragen hinter
einem Wartedialog. Der Mock gibt denselben Bestand heraus und lässt sich
über /api/mock/address-cache leeren, um die Rückfallebene zu prüfen.
Mock hinter dem Profil "mock": Seine Bohnen (/ws und /api/mock/**) hängen
jetzt an @Profile, sind ohne das Profil also nicht vorhanden. Damit kann
der Mock nicht versehentlich in einer Produktivumgebung mitlaufen; das
Container-Image setzt das Profil nicht. Je ein Test hält beide Richtungen
fest.
Webhook: POST /api/webhook nimmt beliebiges JSON eines fremden Systems an
und reicht es über Server-Sent Events an die offenen Browser weiter, wo es
der neue Bereich "Webhook" unverändert anzeigt. Der WebSocket kam dafür
nicht in Frage - er gehört der SwyxTray-App. Das Backend hält die letzten
50 Nachrichten vor und liefert sie beim Wiederverbinden anhand der
Last-Event-ID nach; ein Heartbeat und X-Accel-Buffering: no halten die
Verbindung durch Reverse Proxys hindurch offen. Ein Token (app.webhook.token)
ist vorgesehen, aber nicht voreingestellt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Tag des Images soll bewusst gesetzt werden, nicht aus der pom.xml
hergeleitet. Ohne Argument bricht das Skript mit der Kurzhilfe ab.
Damit entfällt die Auswertung der pom.xml über den Maven-Wrapper - das
Skript braucht backend/mvnw nicht mehr und startet ohne Maven-Lauf. Das
Format ist wieder strikt x.y.z; die Ausnahme fuer -SNAPSHOT gab es nur,
weil die pom.xml als Vorgabe diente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ein Container liefert Startseite und REST-API über Port 8080 aus: Das
Dockerfile baut das Frontend mit Node, legt das Ergebnis in die statischen
Ressourcen des Backends und packt beides mit Maven zum Jar; die Laufzeit-
stufe enthält nur ein JRE und das Jar, ausgeführt als Benutzer swyx.
Die beiden Build-Stufen laufen auf $BUILDPLATFORM, also nativ auf dem
bauenden Rechner - JS-Bundle und Jar sind architekturunabhängig. Nur das
Laufzeit-Image wird für die Zielarchitektur gezogen, was beim Bauen für
linux/amd64 auf einem ARM-Mac die Emulation spart.
docker_push.sh liest die Version aus backend/pom.xml, baut für linux/amd64
und pusht in die Registry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die README beschreibt die Compound-Konfiguration "SwyxWeb starten
(Backend + Frontend)" als Weg, das Projekt zu starten – dann muss sie
auch im Repo liegen. Persönliche Einstellungen (.vscode/settings.json)
bleiben ausgeschlossen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
SvenandClaude Opus 5