- Updated `springBoot` to version `4.0.1` for compatibility improvements.
- Reactivated and explicitly defined `reactor-kafka` dependency.
- Added missing `spring-boot-starter-aop` definition to dependency catalog.
### Summary
- Removed `repositories` blocks from individual `build.gradle.kts` files, moving configuration to `settings.gradle.kts`.
- Replaced custom Spring Boot constraints in the platform BOM with the Spring Boot BOM for cleaner dependency management.
- Explicitly added `webflux` dependency for Gateway to handle transitivity changes in Spring Boot 4.x.
Umfangreiches Refactoring der Projektkonfiguration zur klaren Trennung von Build-, Runtime- und Applikations-Logik.
Änderungen im Detail:
- Struktur: Neuorganisation des `config/` Verzeichnisses in logische Bereiche:
- `config/docker`: Reine Infrastruktur-Configs (Postgres, Redis, Nginx, Monitoring).
- `config/quality`: Statische Code-Analyse (Detekt, Lint).
- `config/app`: Gemeinsame Spring-Boot-Konfigurationen.
- Docker Compose:
- Einführung von Profilen (`infra`, `backend`, `ops`, `gui`, `tools`) für gezieltes Starten von Teilbereichen.
- Anpassung aller Volume-Pfade auf die neue Struktur.
- Spring Boot Config:
- Zentralisierung gemeinsamer Einstellungen (Datasource, Redis, JPA) in `config/app/base-application.yml`.
- Parametrisierung der Hosts für nahtlosen Wechsel zwischen Docker und Localhost.
- Bereinigung der service-spezifischen `application.yaml` Dateien (z.B. Ping-Service).
- Cleanup: Entfernen redundanter "Ghost-Files" (`versions.toml`, `central.toml`, `config/.env`), um eine echte Single Source of Truth (SSoT) zu gewährleisten.
### Summary
- Updated root `README.md` to reflect the new Backend/Frontend structure.
- Rewrote the project structure section to show `backend/` and `frontend/` with their submodules, and `docs/adr` + `docs/c4`.
- Corrected Gradle module examples from old `:members:members-service` paths to `:backend:services:results:results-service` for both `bootRun` and `test` examples.
- Verified links now point to `docs/adr` and `docs/c4`.
- Updated `docs/README.md` to ensure flat paths:
- Confirmed ADR and C4 links point to `adr/` and `c4/` respectively.
- Updated the footer note to today’s date and linked ADR-0009.
These changes align the docs with the consolidated, flat documentation layout and the finalized module structure.
Ref: MP-30
Das Refactoring der Authentifizierungs-Komponenten auf Dependency Injection (Koin) wurde verifiziert und abgeschlossen. Alle manuellen Instanziierungen wurden entfernt und die korrekte Initialisierung in allen Entry-Points sichergestellt.
- Entfernen/Deprecaten: `frontend/features/auth-feature/.../AuthenticatedHttpClient.kt` und alle manuellen `Authorization`‑Header‑Setzungen.
- Stattdessen: DI‑`apiClient` via Koin injizieren (`single(named("apiClient"))`) und Token‑Anreicherung über Ktor `Auth` Plugin (Bearer) verdrahten.
- Build‑Guard ergänzen: Auch Vorkommen von `HttpHeaders.Authorization` erkennen.
* MP-19 Refactoring: Einführung der "Registry" & "Masterdata" Trennung (Clean Architecture)
Architektur-Entscheidung: "Zwei-Welten-Modell" zur Trennung von User-Identität und Verbandsdaten.
Änderungen:
- settings.gradle.kts: Umstrukturierung der Module in 'domains', 'infrastructure', 'core'.
- Modul ':members' wurde zu ':domains:registry' (Single Source of Truth für OEPS-Daten).
- Neues Modul ':domains:registry:oeps-importer' für ZNS-Datenimports (Spring Batch Vorbereitung).
- Neues Modul ':domains:masterdata' für Regelwerke und Kataloge.
- Entfernung/Deaktivierung von Legacy-Modulen, die durch Keycloak (Docker) ersetzt wurden.
Ziel: DSGVO-konforme Trennung von "User" (Auth) und "Person" (Registry) sowie Vorbereitung für Multi-Verband-Support.
* MP-19 Refactoring: Frontend Tabula Rasa
* MP-19 Refactoring: Frontend Tabula Rasa
* refactoring:
Ein umfassender Commit wurde vorgeschlagen, der Zeittypen vereinheitlicht, Fehlercodes zentralisiert und neue Funktionen in core-utils hinzufügt. Es wurden Breaking Changes dokumentiert, insbesondere bei Datenbank-Utilities und Zeit-/Serializer-Konsolidierung. Die Commit-Nachricht folgt dem Conventional Commits-Standard und umfasst mehrere Module.
* MP-20 fix(docker/clients): include `:domains` module in web/desktop builds to fix Gradle configuration error
Docker build der Clients schlug fehl beim Schritt `:clients:app:dependencies` mit:
"Configuring project ':domains' without an existing directory is not allowed. The configured projectDirectory '/app/domains' does not exist..."
Änderungen:
- dockerfiles/clients/web-app/Dockerfile: COPY domains ./domains
- dockerfiles/clients/desktop-app/Dockerfile: COPY domains ./domains
Begründung:
- `settings.gradle.kts` inkludiert `:domains`; der Ordner wurde bisher nicht in das Build-Image kopiert.
- Dadurch konnte Gradle das Multi-Projekt im Container nicht konfigurieren.
Hinweise:
- Keine Laufzeitänderungen, nur Build-Fix.
- Caching bleibt erhalten (COPY vor den Gradle-Schritten).
Rebuild:
- Hardcoded: `docker compose -f compose.hardcoded.yaml build web-app`
- Env-basiert: `docker compose -f compose.yaml build web-app`
* MP-20 fix(web-app build): resolve JS compile error and add dev/prod build profile for Docker
- clients:shared: remove legacy DI wiring to data/PingRepositoryImpl in SharedModule
- dockerfiles/clients/*: copy `domains/` into builder to satisfy multi-project includes
- web-app Dockerfile: add WEB_BUILD_PROFILE (dev|prod), unify dist copy via /app/web-dist
- compose(.yaml|.hardcoded.yaml): pass WEB_BUILD_PROFILE (default dev)
Result: JS build succeeds; flexible dev/prod bundles for faster iteration or optimized assets.
* MP-20 fix(web-app): remove vendor.js reference and harden JS bootstrap so Welcome screen renders
Problem:
- Web UI blieb bei „🚀 Loading Meldestelle…“ stehen, obwohl `web-app.js` (200/304) geladen wurde.
- In DEV gab es keinen `vendor.js`-Chunk → der harte `<script src="vendor.js">`-Eintrag führte zu 404 und verhinderte den Start.
Änderungen:
- clients/app/src/jsMain/resources/index.html
- Entfernt: hart codiertes `<script src="vendor.js" defer></script>`
- Beibehalten: Single-Bundle `<script src="web-app.js" defer></script>` mit Hinweiskommentar
- clients/app/src/jsMain/kotlin/main.kt
- Start-Mechanik robuster gemacht: DOMContentLoaded/readyState-Check, sichtbares Fehlermeldungs-Fallback, Debug-Logs (`[WebApp] …`), Entfernen des „Loading …“-Platzhalters nach Mount
- clients/app/build.gradle.kts
- Sichergestellt: `binaries.executable()` und `mainOutputFileName = "web-app.js"`; keine CommonJS/`libraryTarget`-Konfiguration mehr
- dockerfiles/clients/web-app/Dockerfile
- Build-Profil per `WEB_BUILD_PROFILE=dev|prod` (Default: dev)
- DEV: Single-File-Bundle (developmentExecutable) → `/app/web-dist` → Nginx
- PROD: Distribution-Bundle (productionExecutable) → `/app/web-dist` → Nginx
Warum:
- DEV-Bundle emittiert i. d. R. nur `web-app.js`. Der `vendor.js`‑Request erzeugte 404 und stoppte den App-Start.
- Robuster Bootstrap stellt sicher, dass Compose auch bei unterschiedlichen Ladezeiten zuverlässig mountet.
Verifikation:
- `docker compose -f compose.yaml build web-app && docker compose -f compose.yaml up -d web-app`
- Browser: http://localhost:4000 → Welcome rendert; Network: nur `web-app.js` (200), kein `vendor.js`; Console: keine Fehler, optionale `[WebApp]`‑Logs sichtbar.
Hinweis:
- Für PROD (optional): `WEB_BUILD_PROFILE=prod` bauen; Chunk‑Injektion erfolgt über das Kotlin/JS‑Plugin (keine hart codierten Chunk‑Namen in HTML verwenden).
* MP-20 fixing: clients
* MP-20 fixing: clients
1. Update MemberRepositoryImpl: replace DatabaseFactory.dbQuery calls with explicit Exposed transaction{} and remove the non-existent import; add necessary ExperimentalTime opt-ins and fix Clock usages.
2. Inspect members-infrastructure MemberTable.kt to add missing ExperimentalTime opt-ins and adjust types if needed.
3. Rebuild to surface any remaining Exposed API or import errors and fix them.
4. Verify members-api compiles and that endpoints remain intact; provide final summary.
Ein UseCase zur Sicherstellung von Member-Profilen wurde implementiert und ein Sync-Endpunkt im Backend hinzugefügt. Das Frontend löst nach Login einen einmaligen Sync-Call aus, optional wurde eine Komfortfunktion im MembersApiClient ergänzt. Build und Tests wurden erfolgreich ausgeführt, alle Gateway-Tests sind grün.
Ein Backend-UseCase wurde implementiert, der nach Login prüft, ob ein Member-Profil existiert, und bei Bedarf ein neues Profil mit OEPS-Daten anlegt. Ein API-Endpunkt /api/members/sync wurde hinzugefügt, der vom Frontend nach Login aufgerufen wird. Der Gesamt-Build und die Tests laufen erfolgreich ohne Fehler.
Ein neues Kotlin-Multiplattform-Mitgliedermodul wurde bereitgestellt, das clientseitige API-Aufrufe, Benutzeroberfläche und Navigation in die Host-Anwendung integriert. Der Build wurde durch die Entkopplung von Backend-Mitgliedermodulen stabilisiert, und alle Tests wurden erfolgreich abgeschlossen. Die Client-Funktionen erfolgen über REST-Aufrufe an das Gateway; die Backend-Integration wird in einer späteren Phase implementiert.
Gateway-Profile und Tests wurden geprüft, keine /api/auth/**-Routen gefunden. Projektweite Suche ergab keine buildkritischen Referenzen. Alle Tests und der Build liefen erfolgreich ohne notwendige Codeänderungen.
Die Lösung zentralisierte die Frontend-Konfiguration durch Hinzufügen von AppConfig mit umgebungsspezifischen URLs. Die Clients wurden so umstrukturiert, dass sie AppConfig-Werte anstelle von fest codierten URLs verwenden. Alle Gateway-Tests wurden erfolgreich abgeschlossen und das Projekt konnte ohne schwerwiegende Fehler kompiliert werden.
