chore: refactor Gradle config, standardize Kotlin MPP plugin usage, and update dependencies

- Unified plugin application across modules using `alias(libs.plugins.*)` instead of hardcoded IDs. - Removed redundant JVM/JS source map tasks, improving Gradle and Docker build consistency. - Updated dependencies, including `logback` and Webpack `copy-webpack-plugin`, and added contextual documentation. - Added frontend architecture diagram in PlantUML (`docs/01_Architecture/Reference`), standardizing feature-core-shell dependencies.
2026-02-05 02:07:53 +01:00
parent 1aaaf8a203
commit c3d288cd66
8 changed files with 302 additions and 1 deletions
@@ -0,0 +1,62 @@
+# 🧹 Session Log: Gradle Build-Optimierung & Refactoring
+
+**Datum:** 03.02.2026
+**Teilnehmer:** Lead Architect, User
+**Thema:** Umfassende Analyse, Bereinigung und Optimierung der Gradle Build-Skripte (Frontend, Backend, Platform).
+
+## 📝 Zusammenfassung
+In dieser Session wurde die gesamte Build-Infrastruktur des Projekts "Meldestelle" analysiert und refaktorisiert. Ziel war es, Redundanzen zu eliminieren (DRY), die Konsistenz zwischen Modulen zu erhöhen und die strikte Nutzung des Version Catalogs (`libs.versions.toml`) durchzusetzen. Ein kritischer Fehler im `monitoring-server` (Logback `NoClassDefFoundError`) wurde durch Korrekturen in der Dependency-Hierarchie behoben.
+
+## 🛠️ Durchgeführte Änderungen
+
+### 1. Version Catalog (`libs.versions.toml`)
+*   **Fix:** Syntaxfehler bei `npm-copy-webpack` behoben (NPM-Pakete müssen in `[versions]` definiert und via `devNpm` referenziert werden).
+*   **Neu:** `sqliteWasm` Version hinzugefügt.
+*   **Neu:** `logback-core` hinzugefügt, um Versionskonflikte mit Spring Boot zu vermeiden.
+
+### 2. Root & Settings
+*   **`settings.gradle.kts`**: Hardcodierte Plugin-Versionen entfernt (soweit technisch möglich). Ausnahme: `foojay-resolver` muss aufgrund des Build-Lifecycles hardcodiert bleiben.
+*   **`build.gradle.kts` (Root)**:
+    *   Zentralisierung der Kotlin Compiler-Optionen (JVM 25, `-Xexpect-actual-classes`).
+    *   Globale Konfiguration für `tasks.test` (JUnit Platform, Heap Size).
+    *   Reduzierung von "Noise" bei JS-Builds (Duplicate Strategy).
+
+### 3. Frontend (KMP)
+*   **`frontend/core/*`**:
+    *   Entfernung redundanter `compilerOptions` und `jvmToolchain` Konfigurationen.
+    *   Vereinheitlichung der JS-Target Konfiguration (`browser()`, `binaries.library()`).
+    *   Bereinigung von `auth`, `design-system`, `local-db`, `navigation`, `network`, `sync`.
+*   **`frontend/features/ping-feature`**: Anpassung an Core-Standards.
+*   **`frontend/shells/meldestelle-portal`**:
+    *   Korrektur der Webpack-Konfiguration (`copy-webpack-plugin` via Catalog).
+    *   Vereinfachung der Build-Logik.
+
+### 4. Platform
+*   **`platform-bom`**:
+    *   Aufnahme von `logback-core` in die Constraints, um Synchronität mit `logback-classic` zu erzwingen.
+    *   Bereinigung von auskommentiertem Code.
+*   **`platform-testing`**:
+    *   Explizites Hinzufügen von `logback-classic` und `logback-core`, um Laufzeitfehler in Tests zu verhindern.
+    *   Entfernung redundanter Test-Konfigurationen.
+
+### 5. Backend Infrastructure
+*   Bereinigung aller Module (`cache`, `event-store`, `gateway`, `messaging`, `persistence`, `security`) von redundanten Konfigurationen (DRY).
+*   **Bugfix `monitoring-server`**:
+    *   Problem: `java.lang.NoClassDefFoundError` bei `JoranConfigurator` (Logback).
+    *   Ursache: Versionskonflikt bzw. fehlendes `logback-core` im Test-Classpath durch Spring Boot BOM Interferenz.
+    *   Lösung: Explizites Hinzufügen von `logback-core` und `logback-classic` im `monitoring-server` sowie Anpassung der `platform-bom`.
+
+### 6. Contracts
+*   **`contracts/ping-api`**: Bereinigung und Konsistenzprüfung.
+
+## ⚠️ Technische Highlights & Learnings
+*   **Settings Plugins & Version Catalog**: Der Zugriff auf `libs.*` im `plugins {}` Block der `settings.gradle.kts` ist limitiert. Workaround: Version hardcodieren oder `pluginManagement` nutzen.
+*   **Logback & Spring Boot**: Spring Boot managed Logback-Versionen aggressiv. Wenn man eine neuere Version (1.5.x) nutzen will als Spring Boot (1.4.x), muss man sowohl `classic` als auch `core` in der BOM erzwingen, sonst drohen `NoClassDefFoundError` zur Laufzeit.
+*   **KMP JS Targets**: Die Konfiguration von `js(IR)` vs. `js` und `browser()` vs. `nodejs()` sollte projektweit konsistent sein, um Build-Probleme zu vermeiden.
+
+## ✅ Status
+*   Build: **SUCCESSFUL** (`./gradlew clean build`)
+*   Code Quality: Build-Skripte sind massiv entschlackt und wartbarer.
+
+---
+*Eintrag erstellt durch Curator Agent.*
@@ -0,0 +1,143 @@
+# 🏗️ Journal: Infrastructure Setup & CI/CD Planning
+
+**Datum:** 04.02.2026
+**Autor:** DevOps Engineer & Curator (AI)
+**Status:** 🚧 In Progress (Paused due to technical issues)
+
+## Zusammenfassung
+Nach der erfolgreichen Verifikation des `ping-service` wurde mit der Planung und Einrichtung der CI/CD-Infrastruktur begonnen. Die Entscheidung fiel auf eine **Self-Hosted Lösung** (Gitea + Gitea Runner) auf dem vorhandenen Proxmox-Server, angebunden via **Cloudflare Tunnel** für sicheren Zugriff ohne Portfreigaben.
+
+## 1. Cloudflare Bereinigung (Erledigt ✅)
+Ziel war es, die Domain `mo-code.at` für den Tunnel vorzubereiten, ohne den Mail-Empfang zu stören.
+
+**Durchgeführte Schritte:**
+1.  **Login:** Cloudflare Dashboard -> Domain `mo-code.at` -> DNS -> Records.
+2.  **Gelöscht:**
+    *   `A | mo-code.at | 81.19.145.155`
+    *   `A | www | 81.19.145.155`
+    *   `A | ftp | 81.19.145.155`
+3.  **Behalten & Korrigiert (Mail):**
+    *   `A | mail | 81.19.149.91` -> **Proxy Status auf "DNS Only" (Grau) gesetzt.**
+    *   `CNAME | imap | imap.world4you.com` -> **Proxy Status auf "DNS Only" (Grau) gesetzt.**
+    *   `MX` und `TXT` Records wurden unverändert gelassen.
+
+---
+
+## 2. Proxmox Docker-Host Setup (Anleitung)
+
+Diese Anleitung dient zur Wiederherstellung/Neuinstallation der VM, falls Probleme auftreten.
+
+### Vorbereitung: ISO Download
+1.  Proxmox GUI -> `local` Storage -> `ISO Images`.
+2.  **Download from URL:** `https://releases.ubuntu.com/24.04.1/ubuntu-24.04.1-live-server-amd64.iso`
+3.  Warten bis Download fertig.
+
+### Schritt A: VM Erstellen (Klick-für-Klick)
+1.  **Create VM** (Button oben rechts).
+2.  **General:**
+    *   Name: `docker-host`
+    *   VM ID: (Standard lassen, z.B. 100)
+3.  **OS:**
+    *   ISO image: `ubuntu-24.04.1...iso`
+    *   Type: Linux / 6.x - 2.6 Kernel
+4.  **System:**
+    *   Graphics/Machine/BIOS: Standard lassen.
+    *   **Qemu Agent:** ✅ Aktivieren (Häkchen setzen).
+5.  **Disks:**
+    *   Storage: `local-lvm`
+    *   Disk size: **100 GiB**
+    *   **SSD emulation:** ✅ Aktivieren.
+    *   **Discard:** ✅ Aktivieren.
+6.  **CPU:**
+    *   Sockets: 1
+    *   Cores: **4**
+    *   Type: **host** (Wichtig für Performance!).
+7.  **Memory:**
+    *   Memory: **8192** (8 GB).
+    *   Ballooning: ✅ Aktivieren.
+8.  **Network:**
+    *   Bridge: `vmbr0`
+    *   Model: `VirtIO`
+9.  **Confirm** -> Finish.
+
+### Schritt B: Ubuntu Installation
+1.  VM starten -> **Console**.
+2.  Sprache: English.
+3.  Installer Update: "Update to the new installer" (falls gefragt).
+4.  Keyboard: German.
+5.  **Base:** Ubuntu Server (minimized optional, Standard empfohlen).
+6.  **Network:** DHCP lassen.
+7.  **Storage:** "Use an entire disk" -> Standard lassen -> Done.
+8.  **Profile:**
+    *   Name: `Stefan`
+    *   Server name: `docker-host`
+    *   Username: `stefan`
+    *   Password: (Merken!)
+9.  **SSH Setup:** **[X] Install OpenSSH server** (Mit Leertaste auswählen).
+10. **Snaps:** **NICHTS** auswählen (kein Docker, kein MicroK8s).
+11. Installieren & Reboot.
+
+### Schritt C: Docker Installation (via Terminal/SSH)
+Verbinde dich von deinem PC aus: `ssh stefan@<VM-IP>`
+
+```bash
+# 1. System aktualisieren & QEMU Agent sicherstellen
+sudo apt update && sudo apt upgrade -y
+sudo apt install -y qemu-guest-agent
+sudo systemctl enable --now qemu-guest-agent
+
+# 2. Docker Installations-Script laden & ausführen
+curl -fsSL https://get.docker.com -o get-docker.sh
+sudo sh get-docker.sh
+
+# 3. User zur Docker-Gruppe hinzufügen (Wichtig!)
+sudo usermod -aG docker $USER
+
+# 4. Neustart, damit Rechte greifen
+sudo reboot
+```
+
+### Schritt D: Test
+Nach dem Neustart wieder einloggen:
+```bash
+docker run hello-world
+```
+Sollte "Hello from Docker!" ausgeben.
+
+---
+
+## 3. Ausblick: Nächste Schritte (DevOps Stack)
+
+Sobald der Docker-Host läuft, werden wir folgende `docker-compose.yml` (Entwurf) verwenden, um Gitea und Cloudflare Tunnel zu starten:
+
+```yaml
+services:
+  gitea:
+    image: gitea/gitea:latest
+    container_name: gitea
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
+    volumes:
+      - ./gitea_data:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "2222:22"
+    restart: always
+
+  tunnel:
+    image: cloudflare/cloudflared:latest
+    container_name: cloudflared
+    restart: always
+    command: tunnel run
+    environment:
+      - TUNNEL_TOKEN=<WIRD_GENERIERT>
+```
+
+## Troubleshooting Tipps (Installation bricht ab)
+*   **ISO Check:** Prüfe die Checksumme des ISOs oder lade es neu herunter.
+*   **RAM:** Versuche es testweise mit 4 GB statt 8 GB.
+*   **Disk:** Prüfe im Proxmox Storage, ob wirklich genug Platz auf `local-lvm` frei ist.
+*   **Console:** Beobachte die Fehlermeldung in der Proxmox-Konsole genau (oft I/O Errors).
@@ -0,0 +1,31 @@
+# 🏗️ Journal: Ping Service Verification
+
+**Datum:** 04.02.2026
+**Autor:** Lead Architect (AI)
+**Status:** ✅ Verified
+
+## Zusammenfassung
+Vor dem Start der CI/CD-Pipeline Implementierung wurde der `ping-service` einer umfassenden Prüfung unterzogen. Ziel war es, die Konsistenz von Code, Tests, Docker-Konfiguration und Security-Einstellungen sicherzustellen.
+
+## Prüfergebnisse
+
+### 1. Code & API Konsistenz
+*   **Sync API:** Der Parameter `since` wird konsistent in `PingApi` (Contract) und `PingController` (Backend) verwendet.
+*   **UUID:** Die Verwendung der experimentellen Kotlin UUID API (`v7`) ist durch `@OptIn` Annotationen und Compiler-Args korrekt konfiguriert.
+*   **Tests:** Unit- und Integrationstests (`PingControllerTest`, `PingControllerIntegrationTest`) sind aktuell und decken die API-Änderungen ab.
+
+### 2. Docker Konfiguration
+*   **Base Image:** Alpine-basiertes JRE für minimale Größe und Sicherheit.
+*   **Security:** Non-root User `appuser` wird verwendet.
+*   **Healthcheck:** Korrekt auf `/actuator/health/readiness` konfiguriert. `curl` ist im Image vorhanden.
+*   **Entrypoint:** `tini` wird für korrektes Signal-Handling genutzt.
+
+### 3. Security Konfiguration
+*   **Actuator:** `/actuator/**` ist via `GlobalSecurityConfig` öffentlich zugänglich (notwendig für Docker Healthcheck).
+*   **Endpoints:**
+    *   Public: `/ping/simple`, `/ping/enhanced`, `/ping/public`, `/ping/health`
+    *   Protected: `/ping/secure`, `/ping/sync` (implizit durch `anyRequest().authenticated()`)
+*   **CORS:** Global aktiviert für Frontend-Zugriff.
+
+## Fazit
+Der `ping-service` ist **Ready for Deployment**. Die Architektur ist sauber, sicher und testbar. Wir können nun mit der Einrichtung der CI/CD-Pipeline (Cloudflare, Selfhosted Proxmox) fortfahren.