chore: remove deprecated horses, clubs, officials, and persons services

- Deleted obsolete modules related to horses, clubs, officials, and persons services, including their configurations, build files, and database provisioning scripts. - Cleaned up associated references in the project structure (e.g., `settings.gradle.kts`). - Removed unused database tables and Spring beans related to these domains. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-03-28 16:50:49 +01:00
parent 2cb3f0b125
commit c806660685
181 changed files with 4121 additions and 8694 deletions
@@ -0,0 +1,47 @@
+---
+type: Journal
+status: COMPLETED
+owner: DevOps Engineer
+last_update: 2026-03-28
+---
+
+# Session Log: Korrektur der Spring Boot Konfiguration im Masterdata-Modul
+
+🐧 **[DevOps Engineer]** | 28. März 2026
+
+## Kontext
+
+Der Build schlug im Modul `:backend:services:masterdata:masterdata-infrastructure` beim Task `bootJar` fehl, da keine
+`mainClass` konfiguriert war. Da dieses Modul nur Infrastruktur-Code (Exposed Repositories etc.) bereitstellt und keine
+eigenständige Spring Boot Application ist, sollte kein `bootJar` (ausführbares JAR) erstellt werden.
+
+## Erledigte Aufgaben
+
+### 1. ✅ build.gradle.kts Anpassung
+
+- Das `spring-boot` Plugin in `masterdata-infrastructure/build.gradle.kts` auf `apply false` gesetzt.
+- Dadurch wird der `bootJar` Task (der eine Main-Class zwingend erfordert) für dieses Modul nicht mehr registriert.
+- Der Standard `jar` Task bleibt aktiv und stellt die Library für andere Module zur Verfügung.
+
+### 2. ✅ Build-Verifizierung
+
+- Lokaler Build der betroffenen Tasks erfolgreich durchgeführt:
+  - `./gradlew :backend:services:masterdata:masterdata-infrastructure:jar` (Erfolgreich)
+  - `./gradlew :backend:services:masterdata:masterdata-service:bootJar` (Erfolgreich, nutzt die Infrastruktur-Library)
+- Status: **GRÜN**
+
+## Technische Änderungen
+
+### `backend/services/masterdata/masterdata-infrastructure/build.gradle.kts`
+
+- Geändert: `alias(libs.plugins.spring.boot) apply false`
+
+## Nächste Schritte
+
+- Prüfung anderer Infrastruktur-Module auf ähnliche Fehlkonfigurationen (redundante `bootJar` Tasks).
+
+---
+
+## Referenzen
+
+- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
@@ -0,0 +1,54 @@
+---
+type: Journal
+status: COMPLETED
+owner: DevOps Engineer
+last_update: 2026-03-28
+---
+
+# Session Log: Metaspace-Optimierung & Build-Fix
+
+🐧 **[DevOps Engineer]** | 28. März 2026
+
+## Kontext
+
+Der Build schlug in mehreren Modulen mit `java.lang.OutOfMemoryError: Metaspace` fehl.
+Betroffen waren insbesondere die Kotlin/JS und WASM Kompilationen:
+
+- `:contracts:ping-api:compileKotlinWasmJs`
+- `:core:core-domain:compileTestKotlinJs`
+- `:core:core-utils:compileKotlinJs`
+
+Die bisherigen Limits (1GB Metaspace) reichten für die komplexe Multiplatform-Struktur nicht mehr aus.
+
+## Erledigte Aufgaben
+
+### 1. ✅ Metaspace & Heap Erhöhung
+
+- Metaspace-Limit für den Kotlin Daemon und den Gradle Daemon von **1GB auf 2GB** erhöht.
+- Heap-Speicher für den Kotlin Daemon von **4GB auf 6GB** erhöht.
+- Redundante/widersprüchliche JVM-Argumente in `gradle.properties` harmonisiert.
+
+### 2. ✅ Build-Verifizierung
+
+- Lokaler Build der betroffenen Tasks erfolgreich durchgeführt:
+  `./gradlew :contracts:ping-api:compileKotlinWasmJs :core:core-domain:compileTestKotlinJs :core:core-utils:compileKotlinJs --no-daemon`
+- Status: **GRÜN**
+
+## Technische Änderungen
+
+### `gradle.properties`
+
+- `kotlin.daemon.jvmargs`: `-Xmx6g -XX:MaxMetaspaceSize=2g`
+- `org.gradle.jvmargs`: `-Xmx6g -Dkotlin.daemon.jvm.options="-Xmx4g" -XX:MaxMetaspaceSize=2g`
+
+## Nächste Schritte
+
+- Überwachung der CI/CD Pipeline auf ähnliche Ressourcen-Engpässe.
+- Bei weiteren Problemen: Prüfung, ob `--parallel` in Kombination mit vielen JS-Targets zu hohen Lastspitzen führt.
+
+---
+
+## Referenzen
+
+- `gradle.properties`
+- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
@@ -0,0 +1,50 @@
+---
+type: Journal
+status: COMPLETED
+owner: QA Specialist
+last_update: 2026-03-28
+---
+
+# Session Log: Behebung Flyway Migrations-Fehler (Ping-Service)
+
+🧐 **[QA Specialist]** | 28. März 2026
+
+## Kontext
+
+Der Test-Task `:backend:services:ping:ping-service:test` schlug fehl. Die Ursache war ein `FlywayMigrateException` mit
+der Meldung `ERROR: relation "ping" already exists`.
+Dies passierte, weil zwei separate Migrations-Dateien versuchten, die gleiche Tabelle `ping` zu erstellen.
+
+## Erledigte Aufgaben
+
+### 1. ✅ Identifizierung des Konflikts
+
+- `V1__init_ping.sql` enthielt bereits die `CREATE TABLE ping` Anweisung.
+- `V3__.sql` (vermutlich ein automatisches Relikt oder Fehl-Generat) versuchte die gleiche Tabelle erneut anzulegen.
+
+### 2. ✅ Bereinigung
+
+- Die redundante Datei `backend/services/ping/ping-service/src/main/resources/db/migration/V3__.sql` wurde gelöscht.
+- `V1__init_ping.sql` (Schema) und `V2__seed_data.sql` (Testdaten) bleiben als Basis bestehen.
+
+### 3. ✅ Test-Verifizierung
+
+- Ausführung von `./gradlew :backend:services:ping:ping-service:test`
+- Ergebnis: **BUILD SUCCESSFUL**
+- Alle Tests (Controller, Service, Repository mit Testcontainers) sind grün.
+
+## Technische Details
+
+- Die Warnung bezüglich `sun.misc.Unsafe` (ByteBuddy) in Java 25 wurde zur Kenntnis genommen, blockiert den Build aber
+  nicht und ist ein bekanntes Upstream-Thema bei Spring Boot / Hibernate auf neuesten JDKs.
+
+## Nächste Schritte
+
+- Überwachung der Schema-Generierung in anderen Services, um ähnliche Duplikate zu vermeiden.
+
+---
+
+## Referenzen
+
+- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
+- `backend/services/ping/ping-service/src/main/resources/db/migration/`
@@ -0,0 +1,59 @@
+---
+type: Journal
+status: COMPLETED
+owner: Frontend Expert
+last_update: 2026-03-28
+---
+
+# Session Log: Modernisierung der Tab-Komponenten (Material 3)
+
+🎨 **[Frontend Expert]** | 28. März 2026
+
+## Kontext
+
+Die generische `TabRow`-Komponente aus Material 3 wurde als `@Deprecated` markiert. Gemäß den aktuellen Guidelines muss
+sie durch `PrimaryTabRow` oder `SecondaryTabRow` ersetzt werden, um eine bessere semantische Trennung und konsistente
+Visualisierung (Indikatoren, Divider) zu gewährleisten.
+
+## Erledigte Aufgaben
+
+### 1. ✅ Ersetzung in `turnier-feature`
+
+- In `TurnierAbrechnungTab.kt` wurde die `TabRow` für die Sidebar durch `SecondaryTabRow` ersetzt.
+- Eine fehlerhafte/veraltete `SecondaryTabRow` im Hauptbereich wurde korrigiert und vereinfacht (Entfernung von
+  manuellem `tabIndicatorOffset`).
+- Redundante und fehlerhafte Hilfsmethoden für `tabIndicatorOffset` wurden entfernt.
+
+### 2. ✅ Ersetzung in `veranstaltung-feature`
+
+- In `VeranstaltungUebersichtScreen.kt` wurde die Header-`TabRow` durch `PrimaryTabRow` ersetzt.
+
+### 3. ✅ Build & Verifizierung
+
+- Test-Kompilation der betroffenen Module erfolgreich:
+  - `:frontend:features:turnier-feature:compileKotlinJvm`
+  - `:frontend:features:veranstaltung-feature:compileKotlinJvm`
+- Alle unpräfixierten `TabRow`-Aufrufe im Projekt wurden identifiziert und (wo nötig) migriert.
+
+## Technische Änderungen
+
+### `TurnierAbrechnungTab.kt`
+
+- Wechsel zu `SecondaryTabRow` für Sidebar und Hauptbereich.
+- Cleanup der Imports und Entfernung von `androidx.compose.material` Relikten.
+
+### `VeranstaltungUebersichtScreen.kt`
+
+- Wechsel zu `PrimaryTabRow` für den Haupt-Header.
+
+## Nächste Schritte
+
+- Prüfung weiterer Screens auf ähnliche Deprecations bei zukünftigen Material 3 Updates.
+- Visueller Abgleich mit Figma Vision_03 nach der Migration der restlichen UI-Komponenten.
+
+---
+
+## Referenzen
+
+- Material 3 Design Guidelines (Tabs)
+- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)