From 052169e058f858be3d8bd3b70b6af88e20165b26 Mon Sep 17 00:00:00 2001 From: Kai Moritz Date: Sat, 30 May 2026 00:34:51 +0000 Subject: [PATCH] =?utf8?q?CLAUDE.md:=20Skripte=20=C3=BCberarbeitet,=20alte?= =?utf8?q?=20Referenzen=20entfernt?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit - Skript-Tabelle um detaillierte Beschreibungen ergänzt - Abschnitt für Skripte im technik-check--vorlage-Branch hinzugefügt - Alle Verweise auf alte Großbuchstaben-Skripte (BRANCHES.sh, REBASE.sh, PUSH.sh, RESET.sh, DIFF.sh, TAG.sh) auf neue Namen aktualisiert - Einleitung "Manueller Rebase-Workflow" ohne REBASE.sh-Referenz neu formuliert - config/flawed-setup--zookeeper vollständig entfernt Co-Authored-By: Claude Sonnet 4.6 --- CLAUDE.md | 43 +++++++++++++++++++++++++++---------------- 1 file changed, 27 insertions(+), 16 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 75afaaae..86d41edc 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -199,19 +199,30 @@ Alle Skripte laden zuerst `branches.sh`, das die vollständige Branch-Liste defi | Skript | Zweck | |--------|-------| -| `branches.sh` | Definiert alle Branch-Namen und die Iterationsliste `$BRANCHES` | -| `push.sh` | Force-pusht alle Branches zu origin (erstellt vorher zeitgestempelte Backup-Tags) | -| `reset.sh` | Setzt alle Branches auf `origin/` oder auf ein Tag-Präfix zurück (`./reset.sh `) | -| `diff.sh` | Diff jedes Branches: gegen Remote (kein Arg), gegen Tag-Suffix (1 Arg) oder zwischen zwei Tags (2 Args) | -| `build.sh` | Baut alle Branches (Maven + Gradle); mit `--publish` auch Docker-Images veröffentlichen | -| `copy.sh` | Kopiert Branches in `../vorlagen`-, `../livecoding`-, `../spickzettel`-Verzeichnisse; mit `--nexus-url=` Gradle-Setups für Nexus patchen | -| `patch-nexus.sh` | Patcht `build.gradle`, `settings.gradle` und optional `gradle-wrapper.properties` für internen Nexus-Mirror | +| `branches.sh` | Definiert alle Branch-Namen als Variablen und die Iterationsliste `$BRANCHES` | +| `push.sh` | Force-pusht alle Branches zu origin; erstellt vorher zeitgestempelte Backup-Tags der Remote-Stände | +| `reset.sh` | Ohne Argument: setzt alle Branches auf `origin/` zurück. Mit Argument: auf Tag `--` | +| `diff.sh` | Ohne Arg: lokaler Branch gegen `origin/`. Ein Arg: gegen `--`. Zwei Args: `--` gegen `--` | +| `build.sh` | Baut alle Branches (erkennt Maven/Gradle automatisch); `--vorlage`-Branches werden übersprungen. Mit `--publish`: Docker-Images veröffentlichen | +| `copy.sh` | Kopiert Branches in `../vorlagen`-, `../livecoding`-, `../spickzettel`-Verzeichnisse. Optionaler Tag-Suffix als erstes Argument kopiert den jeweiligen Tag-Stand. Mit `--nexus-url=` werden Gradle-Setups anschließend für einen internen Nexus gepatcht | +| `patch-nexus.sh` | Patcht `build.gradle` (Nexus als Repository), `settings.gradle` (pluginManagement) und optional mit `--gradle-dist-url=` auch `gradle-wrapper.properties`. Wird aus dem Zielverzeichnis (`../vorlagen/`) aufgerufen | Nach Massenoperationen immer zu `scripting` zurückkehren — Skripte führen am Ende `git checkout scripting` aus. +### Skripte im `springkafka/technik-check--vorlage`-Branch + +Dieser Branch enthält zwei zusätzliche Skripte für das Gradle-Setup: + +| Skript | Zweck | +|--------|-------| +| `bootstrap-gradle.sh` | Erzeugt den fehlenden `gradle-wrapper.jar` (per lokaler Gradle-Installation oder Download von GitHub). Mit `--distribute`: kopiert JAR und `gradlew` in alle Geschwister-Übungsverzeichnisse | +| `README-gradle.sh` | Wie `README.sh`, aber für den Gradle-Build: ruft zuerst `bootstrap-gradle.sh` auf, baut dann mit `./gradlew bootBuildImage` | + +`gradle-wrapper.jar` ist absichtlich nicht im Repository (wird von Unternehmens-Mail-Filtern blockiert). `gradlew` und `gradle/wrapper/gradle-wrapper.properties` sind versioniert. + ### TGZ-Verzeichnisstruktur -Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branch `springkafka/technik-check--vorlage` wird als `springkafka/technik-check/` extrahiert. Von dort ist `../..` das Trainings-Wurzelverzeichnis. Das nutzt `bootstrap-gradle.sh` mit `--distribute`, um Gradle-Wrapper-Dateien in alle Geschwister-Übungsverzeichnisse zu kopieren. +Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branch `springkafka/technik-check--vorlage` wird als `springkafka/technik-check/` extrahiert. Von dort ist `../..` das Trainings-Wurzelverzeichnis — so funktioniert `bootstrap-gradle.sh --distribute` korrekt. **Sonderfall `copy.sh`**: `springkafka/technik-check--vorlage` wird nach `vorlagen/grundlagen/technik-check/` kopiert (nicht `vorlagen/springkafka/`), da der Technik-Check thematisch zu den Grundlagen-Vorlagen gehört. @@ -219,7 +230,7 @@ Branch-Namen bilden auch die Verzeichnisstruktur im verteilten TGZ ab: Der Branc Diese beiden Stellen müssen immer gemeinsam aktualisiert werden — sie halten unterschiedliche Informationen: -**In `BRANCHES.sh`** (Branch-Name und Iterationsliste): +**In `branches.sh`** (Branch-Name und Iterationsliste): 1. Variablenname und -wert (Branch-Name) als neue Zeile eintragen. 2. Variablenname in die `$BRANCHES`-Iterationsliste aufnehmen. @@ -252,7 +263,7 @@ Wird eine Klasse oder Datei in einen neuen Branch verschoben (oder ein neuer Spi ## Manueller Rebase-Workflow -Das `REBASE.sh`-Skript automatisiert das Rebasen prinzipiell, aber in der Praxis entstehen häufig Konflikte, weil Branches sich absichtlich unterscheiden — sie demonstrieren verschiedene Aspekte von Kafka. Claude Code übernimmt die Rolle des Menschen, der bisher manuell eingreifen musste. +Rebases werden immer manuell durchgeführt, weil Branches sich absichtlich unterscheiden — sie demonstrieren verschiedene Aspekte von Kafka. Konflikte erfordern fachliches Urteil darüber, was absichtliche und was unbeabsichtigte Divergenz ist. ### Ansatz zur Konfliktlösung @@ -267,7 +278,7 @@ In diesen Fällen: Problem zeigen, erklären warum es wichtig ist, und einen kon ### Allgemeine Prinzipien -- Branch für Branch in der Reihenfolge arbeiten, wie in `BRANCHES.sh` definiert +- Branch für Branch in der Reihenfolge arbeiten, wie in `branches.sh` definiert - Zwischen **absichtlichen** Unterschieden (verschiedene Lernziele) und **unbeabsichtigten** Unterschieden (Zeitdruck, vergessene Backports) unterscheiden - Verbesserungen von späteren auf frühere Branches zurückportieren, wo sinnvoll - Nach dem Rebasen immer zum `scripting`-Branch zurückkehren @@ -278,7 +289,7 @@ Live-Codings verbinden die technischen Lücken zwischen den Übungsgruppen. Jede ### Struktur eines Live-Codings -**Schritt 0** (`--livecoding`-Branch): Die Anwendung aus dem Ausgangsbranch wird auf die Benennung der Anwendung im Zielbranch umbenannt (mit dem Zusatz `--livecoding`) und das Setup entsprechend vorbereitet. Der Ausgangsbranch ist der ROOT des `--livecoding`-Branches in `BRANCHES.sh`. +**Schritt 0** (`--livecoding`-Branch): Die Anwendung aus dem Ausgangsbranch wird auf die Benennung der Anwendung im Zielbranch umbenannt (mit dem Zusatz `--livecoding`) und das Setup entsprechend vorbereitet. Der Ausgangsbranch ist der ROOT des `--livecoding`-Branches (nachzuschlagen in der ROOT-Tabelle dieser `CLAUDE.md`). **Schritte 1–N** (`--livecoding--schritte`-Branch): Die Anwendung und das Setup werden Schritt für Schritt so umgebaut, dass sie dem Zustand im Zielbranch annähernd entsprechen. Der Zielbranch enthält ggf. noch weitere "off-topic"-Features als "Best Practices", sodass 100% Übereinstimmung weder erwartet noch nötig ist. @@ -328,7 +339,7 @@ Image-Name muss immer `juplo/:` (Maven) oder `juplo/${proje ### ROOT eines Branches ermitteln -Der ROOT jedes Branches steht in der **ROOT-Tabelle in dieser `CLAUDE.md`** (Abschnitt „Branch-Hierarchie"). **Vor jedem Rebase dort nachschlagen** — nicht in `BRANCHES.sh` greifen, da die Tabelle hier bereits vollständig und geprüft ist. +Der ROOT jedes Branches steht in der **ROOT-Tabelle in dieser `CLAUDE.md`** (Abschnitt „Branch-Hierarchie"). **Vor jedem Rebase dort nachschlagen** — nicht in `branches.sh` greifen, da die Tabelle hier bereits vollständig und geprüft ist. Als Gegencheck lässt sich der ROOT auch aus dem Branch-HEAD ableiten: ```bash @@ -411,7 +422,7 @@ Um die wirklich neuen Inhalte einer Session zu identifizieren, nicht die Anzahl ### Session-Tagging-Schema -Jede Rebase-Session taggt jeden abgeschlossenen Branch als `--claude-N`. Die Tag-Nummer erhöht sich pro Session. Tags dienen als Wiederherstellungspunkte — `./RESET.sh claude-N` setzt alle Branches auf die entsprechenden Tags zurück. Immer direkt nach Abschluss eines Branches taggen, bevor mit dem nächsten begonnen wird. +Jede Rebase-Session taggt jeden abgeschlossenen Branch als `--claude-N`. Die Tag-Nummer erhöht sich pro Session. Tags dienen als Wiederherstellungspunkte — `./reset.sh claude-N` setzt alle Branches auf die entsprechenden Tags zurück. Immer direkt nach Abschluss eines Branches taggen, bevor mit dem nächsten begonnen wird. **Am Ende jeder Session: alle Branches taggen** — auch solche, die sich in dieser Session nicht geändert haben. Branches ohne neue Änderungen erhalten ein `--claude-N`-Tag auf demselben Commit wie ihr `--claude-(N-1)`-Tag: ```bash @@ -426,6 +437,6 @@ done ## Wesentliche Einschränkungen -- `PUSH.sh` force-pusht — das ist für diesen Schulungsworkflow absichtlich und erwartet. +- `push.sh` force-pusht — das ist für diesen Schulungsworkflow absichtlich und erwartet. - `--vorlage`-Branches werden von Build-Skripten übersprungen (sie sind absichtlich unvollständig). -- Der `grundlagen/docker`-Branch ist nicht in `$BRANCHES`, wird aber in mehreren Skripten explizit behandelt (PUSH, DIFF, RESET, TAG). +- Der `grundlagen/docker`-Branch ist nicht in `$BRANCHES`, wird aber in mehreren Skripten explizit behandelt (`push.sh`, `diff.sh`, `reset.sh`). -- 2.39.5