chore(build, dependencies): add Room support with KSP integration and optimize testing dependencies
- Integrated Room plugin and runtime dependencies into `local-db` module, including schema configuration for Room. - Added KSP processor dependencies for Kotlin Multiplatform compatibility. - Enhanced `core-domain` module by refining and temporarily adjusting testing dependencies for resolution issues.
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
# Open-Source-Konformität & Lizenz-Checkliste
|
||||
|
||||
Dieses Dokument dient der Überwachung und Sicherstellung der Open-Source-Konformität des Projekts **Meldestelle**. Es wird vom Lead Architect gepflegt.
|
||||
|
||||
## Status der Kern-Komponenten (Stand: Januar 2026)
|
||||
|
||||
| Komponente | Lizenz | Status | Risiko | Maßnahme / Kommentar |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **Kotlin / JVM** | Apache 2.0 / GPLv2+CE | ✅ OK | Sehr gering | Standard-Stack. |
|
||||
| **Spring Boot / Cloud** | Apache 2.0 | ✅ OK | Sehr gering | |
|
||||
| **PostgreSQL** | PostgreSQL (BSD-like) | ✅ OK | Sehr gering | |
|
||||
| **Redis** | **RSALv2 / SSPL** | ⚠️ KRITISCH | Hoch | **Umstieg auf Valkey (BSD) geplant.** |
|
||||
| **Consul** | **BSL 1.1** | ⚠️ BEOBACHTEN | Mittel | Lizenzänderung durch HashiCorp. Für interne Nutzung aktuell unkritisch. |
|
||||
| **Keycloak** | Apache 2.0 | ✅ OK | Gering | |
|
||||
| **SQLDelight** | Apache 2.0 | ✅ OK | Sehr gering | |
|
||||
| **Redisson** | Apache 2.0 (Core) | ✅ OK | Gering | Sicherstellen, dass keine PRO-Features genutzt werden. |
|
||||
|
||||
---
|
||||
|
||||
## Checkliste für neue Abhängigkeiten
|
||||
|
||||
Bevor eine neue Bibliothek oder Infrastruktur-Komponente hinzugefügt wird, muss sie folgende Kriterien erfüllen:
|
||||
|
||||
1. **Lizenz-Typ:**
|
||||
* Bevorzugt: Apache 2.0, MIT, BSD (3-Clause).
|
||||
* Akzeptabel: MPL 2.0.
|
||||
* Einzelfallprüfung: LGPL (nur als dynamische Bibliothek).
|
||||
* **Verboten:** AGPL, SSPL, RSAL, BSL (sofern nicht explizit vom Architect freigegeben).
|
||||
|
||||
2. **Community & Governance:**
|
||||
* Wird das Projekt von einer neutralen Foundation (Apache, CNCF, Linux Foundation) verwaltet?
|
||||
* Gibt es eine "Single Vendor" Abhängigkeit (Risiko einer plötzlichen Lizenzänderung)?
|
||||
|
||||
3. **Transitive Abhängigkeiten:**
|
||||
* Bringt die Bibliothek "versteckte" Copyleft-Lizenzen mit? (Check via Gradle License Plugin).
|
||||
|
||||
---
|
||||
|
||||
## TODOs & Strategische Entscheidungen
|
||||
|
||||
- [ ] **Migration Redis -> Valkey:** Umstellung der Docker-Images und Test der Kompatibilität.
|
||||
- [ ] **Consul Review:** Jährliche Prüfung der BSL-Auswirkungen auf unser Deployment-Modell.
|
||||
- [ ] **Automatisierung:** Integration eines License-Check-Plugins in den CI-Build (z.B. `com.github.jk1.dependency-license-report`).
|
||||
|
||||
---
|
||||
*Dieses Dokument ist Teil der "Docs-as-Code" Strategie und muss bei jeder Änderung am Tech-Stack aktualisiert werden.*
|
||||
@@ -0,0 +1,36 @@
|
||||
# Backend Roadmap - Meldestelle
|
||||
|
||||
Dieses Dokument beschreibt die geplanten Schritte zur Weiterentwicklung der Backend-Infrastruktur. Der aktuelle Fokus liegt auf der **Härtung der Infrastruktur** unter Nutzung des `ping-service` als technischem Blueprint.
|
||||
|
||||
## Status Quo
|
||||
* **Blueprint:** `ping-service` ist funktional, dient aber nun als Zielobjekt für Infrastruktur-Verbesserungen.
|
||||
* **Technologie:** Spring Boot 3.5.9, Kotlin Coroutines, PostgreSQL.
|
||||
|
||||
## Meilensteine (Priorisiert)
|
||||
|
||||
### Meilenstein 1: Infrastruktur-Härtung (Fokus: Ping-Service)
|
||||
* [ ] **Observability & Monitoring:**
|
||||
* Vollständige Integration von Spring Boot Actuator.
|
||||
* Konfiguration von Micrometer/Prometheus Metriken.
|
||||
* Logging-Standardisierung (Structured Logging/JSON für ELK/Loki).
|
||||
* [ ] **Security Baseline:**
|
||||
* Integration von Spring Security mit Keycloak (OAuth2/OIDC).
|
||||
* Absicherung der Endpunkte im `ping-service` (RBAC).
|
||||
* Validierung der JWT-Tokens am API-Gateway.
|
||||
* [ ] **Resilience & Stability:**
|
||||
* Härtung des Resilience4j Setups (Circuit Breaker, Bulkhead, Rate Limiter).
|
||||
* Optimierung der Datenbank-Connection-Pools (HikariCP).
|
||||
* Einführung von Flyway oder Liquibase für kontrollierte DB-Migrationen.
|
||||
|
||||
### Meilenstein 2: Build-System & CI/CD Readiness
|
||||
* [ ] **Gradle Refactoring:** Umstellung auf Version Catalog (`libs.versions.toml`) für alle Backend-Module.
|
||||
* [ ] **Test-Härtung:** Standardisierung der Integrationstests mit Testcontainers (Postgres, Keycloak, Redis).
|
||||
* [ ] **Docker-Optimierung:** Multi-stage Builds und Distroless-Images für reduzierte Angriffsfläche.
|
||||
|
||||
### Meilenstein 3: Rollout auf Fach-Services
|
||||
* [ ] Übertragung der gehärteten Standards vom `ping-service` auf `horses`, `members`, etc.
|
||||
* [ ] Dokumentation der "Production Readiness Checklist" für neue Services.
|
||||
|
||||
## Nächste Schritte (Vorschlag)
|
||||
1. **Audit des aktuellen `ping-service`:** Identifikation von Lücken in Security und Monitoring.
|
||||
2. **Zentralisierung der Abhängigkeiten:** Einführung der `libs.versions.toml`, um eine konsistente Basis für die Härtung zu haben.
|
||||
Reference in New Issue
Block a user