bootstrap-gradle.sh → init-exercises.sh: Schulungs-Initialisierung verallgemeinert

- bootstrap-gradle.sh ersetzt durch init-exercises.sh mit --maven (Standard) und --gradle
- --gradle: verteilt Wrapper (JAR + properties + gradlew) in alle Übungsverzeichnisse
  (vorlagen/, livecoding/, spickzettel/), entfernt Maven-Artefakte (pom.xml,
  .maven-dockerexclude); scheitert mit Fehler wenn Wrapper noch nicht bereit
- --maven: entfernt verteilte Gradle-Artefakte aus allen Übungsverzeichnissen
- Beide Modi: löschen Build-Ausgaben (target/, build/) und Caches (.gradle/)
- README-gradle.sh: enthält jetzt die Wrapper-Download-Logik mit --update-Schalter;
  ohne --update scheitert es laut, wenn installierte Version nicht zur benötigten passt
- .gitignore: gradle/wrapper/.gradle-version (Versions-Marker) ergänzt

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

bootstrap-gradle.sh: --distribute auf build.gradle als Detektor umgestellt

gradle-wrapper.properties ist nicht in allen Gradle-Übungsbranches vorhanden,
build.gradle hingegen immer. Zielpfade entsprechend direkt aus dem
Übungsverzeichnis berechnet; gradle/wrapper/ wird bei Bedarf angelegt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

bootstrap-gradle.sh: Execute-Bit gesetzt

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

README-gradle.sh: Bootstrap-Skript und ./gradlew verwenden

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

bootstrap-gradle.sh: Bootstrap-Skript für Gradle-Wrapper-JAR hinzugefügt

Erzeugt den fehlenden `gradle-wrapper.jar` entweder über eine lokale
Gradle-Installation oder durch direkten Download von GitHub. Mit
`--distribute` wird der JAR auch in alle Geschwister-Übungsverzeichnisse
kopiert (setzt TGZ-Verzeichnisstruktur voraus, in der Branch-Namen die
Verzeichnishierarchie abbilden).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Gradle-Wrapper-Dateien hinzugefügt (ohne JAR)

`gradlew` und `gradle-wrapper.properties` sind Textdateien und können
problemlos versioniert werden. Der binäre `gradle-wrapper.jar` hingegen
wird von Mail-Sicherheitsfiltern blockiert und daher explizit aus dem
Repository ausgeschlossen (`.gitignore` entsprechend angepasst).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

README-gradle.sh: Gradle-Task auf bootBuildImage korrigiert

Hilfestellung für lokale Gradle-Installationen ergänzt

Tippfehler im Projektnamen korrigiert

Name in den Gradle-Settings an die POM angepasst

README-Skripte für Maven und Gradle angepasst

Separate `README.sh` für Maven und Gradle

`ExampleProducer` auf das `KafkaTemplate` umgestellt

Umbau auf Autoconfig von Spring Kafka

pom.xml/build.gradle: git-Info-Plugins nur ausführen, wenn .git-Verzeichnis existiert

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Docker-Build auf bootBuildImage (Cloud Native Buildpacks) umstellen

Maven nutzte das io.fabric8:docker-maven-plugin, Gradle kopierte das JAR
in ein target/-Verzeichnis für dasselbe Dockerfile.

Beide Build-Systeme nutzen jetzt bootBuildImage, das über Cloud Native
Buildpacks direkt aus dem Spring Boot Plugin heraus ein OCI-Image erzeugt:

  Maven:  mvn spring-boot:build-image
  Gradle: ./gradlew bootBuildImage

Vorteile:
- Kein Dockerfile nötig
- Beide Build-Systeme verwenden dieselbe Methode
- Image folgt automatisch Best Practices (non-root, layered JAR)
- jib-maven-plugin und gradle-git-properties waren bereits durch Rebase
  vorhanden; jib entfällt zugunsten des Spring-Boot-eigenen build-image

Außerdem: springBoot { buildInfo() } in Gradle ergänzt, analog zum
build-info-Goal des spring-boot-maven-plugin (bereits in Maven konfiguriert).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Doku von Spring Kafka empfiehlt `@DirtiesContext` bei `@EmbeddedKafka`

* In diesem einfachen Test ist die Annotation eigentlich überflüssig

Migration Spring-Boot 3.4.1 -> 4.0.2 (producer/spring-producer)

`ExampleProducer` in eine Spring-Boot App umgebaut (ohne Spring Kafka)

* Validierung der Properties aktiviert
* Steuerung und Abfrage über die Actuator-REST-API von ermöglicht
* Namespace für Konfig von `producer` in `juplo.producer` geändert
* In der Configuration wird das Interface des `KafkaProducer` übergeben
* Producerspezifische Properties werden in eigener nested Class verwaltet
** Dadurch wird der Code übersichtlicher, wenn spätere Implementierungen
   _sowohl_ als Consumer, _als auch_ als Producer agieren!
* Das Throttling kann über `juplo.producer.throttle-ms` gesteuert werden
* `delivery.timeout.ms` und `request.timeout.ms` noch weiter gesenkt
* `max.block.ms` auf 5s gesetzt
** Sonst entsteht bei verschiedenen Fehlern schnell ein falscher Eindruck
** Man könnte sonst auf die Idee kommen, dass der Producer für diese
   beliebig lange wartet!
* Eine Exception im Producer löst das Beenden der App aus
* Fix: `close()` muss noch vom `ExampleProducer` aufgerufen werden
** Der Aufruf von `close()` löst das Versenden wartender Nachrichten aus.
** Wenn die Methode erst von Spring aufgerufen wird, werden ggf. noch
   Nachrichten konsumiert, nachdem der `ExampleProducer` bereits
   ausgegeben hat, wieviele Nachrichten er insgesamt verarbeitet hat.
* `delivery.timeout.ms` konfigurierbar gemacht
* `max.block.ms` konfigurierbar gemacht
* `buffer.memory` konfigurierbar gemacht

Migration Spring-Boot 4.0.2 -> 4.0.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Überflüssige Docker-Hilfsdateien entfernen

.dockerignore und .maven-dockerinclude gehören zum alten
Dockerfile/fabric8-basierten Build-Workflow und werden von
Jib bzw. bootBuildImage nicht benötigt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Dockerfile und manuelle Jar-Packaging-Konfiguration entfernen

Seit der Umstellung auf Jib ist das Dockerfile nicht mehr nötig.
maven-dependency-plugin und maven-jar-plugin-Konfiguration (Classpath-
Manifest) waren nur für den manuellen Docker-Build-Weg erforderlich.
Jib übernimmt das Packaging vollständig; mainClass ist nun explizit
in der Jib-Konfiguration gesetzt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

refactor: Docker-Build von fabric8/bmuschko auf Jib umstellen

Maven nutzte das io.fabric8:docker-maven-plugin mit einem handgepflegten
Dockerfile. Gradle kopierte das JAR umständlich in ein target/-Verzeichnis,
damit dasselbe Dockerfile funktioniert (COPY target/*.jar).

Beide Build-Systeme nutzen jetzt Jib (com.google.cloud.tools:jib-maven-plugin
bzw. com.google.cloud.tools.jib), das direkt aus den compilierten Klassen
und Abhängigkeiten ein OCI-Image erzeugt:

  Maven:  mvn package  (jib:dockerBuild ist an package-Phase gebunden)
  Gradle: ./gradlew jibDockerBuild

Für den Registry-Push:
  Maven:  mvn jib:build
  Gradle: ./gradlew jib

Vorteile:
- Kein Dockerfile mehr nötig (kein Kopier-Hack in Gradle)
- Beide Build-Systeme verwenden dieselbe Methode
- Optimiertes Layering (Abhängigkeiten in separaten Layern)
- Kein laufender Docker-Daemon für den Build nötig

Außerdem: gradle-git-properties Plugin hinzugefügt, analog zum
git-commit-id-plugin in Maven.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix: Lombok in Maven korrekt als optional deklarieren

Lombok war mit <scope>compile</scope> deklariert, was dazu führt, dass
es als transitive Abhängigkeit weitergegeben wird. Da Lombok ein reines
Compile-Zeit-Tool (Annotation Processor) ist, muss es als <optional>true</optional>
markiert werden. Der Spring-Boot-Maven-Plugin schließt optionale
Abhängigkeiten automatisch aus dem fat-JAR aus.

Das Gradle-Setup ist in diesem Punkt bereits korrekt (compileOnly +
annotationProcessor).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Client-ID in Shutdown-Meldungen ergänzt

Limits für die Definition des Service `producer` ergänzt

* Dadurch wird die Gefahr eingegrenzt, dass der Arbeitsplatz eines TN
  überlastet wird.
* Dies ist einigen TN passiert, weil sie den `ExampleProducer` ohne
  `Thread.sleep(500)` als Image gebaut haben.
* Wenn dieser dann unbedacht im Hintergrund weiterläuft, kann das den
  Rechner schnell lahm legen...

Eindeutigere Benennung der erfassten Zeitstempel

Upgrade von Spring-Boot 3.4.1 -> 4.0.2 (grundlagen/simple-producer)

Der Producer zählt statt der gesendeten Nachrichten die in der Queue

Fehlermeldung & Abbruch anstatt hartkodierter Standard-Konfig

Einrückung so, wie es IntelliJ will...

`build.gradle` so erweitert, dass das Image gebaut werden kann

Gradle-Wrapper entfernt

Gradle-Konfiguration für Version 8.11.1 hinzugefügt (mit Wrapper!)

Lombok benötigt nur den Scope `compile`

Maven-Wrapper wieder entfernt - Stört Firewalls beim verschicken

Partition & Offset stehen eindeutig in der Log-Meldung

Logmeldungen verwenden Methodenparameter, wo möglich

Maven-Wrapper von Spring-Boot ergänzt und `README.sh` angepasst

Spring-Boot auf 3.4.1 aktualisiert

Bei einem unerwarteten Fehler wird auch der Stacktrace mit ausgegeben

Der Nachrichten-Wert wird in allen Log-Meldungen mit ausgegeben

Logging-Pattern überarbeitet

Unnötige Kommandos aus der `README.sh` entfernt

`docker` in `simple-producer` verwandelt`

Migration Apache-Kafka 4.1.1 -> 4.1.2

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

CPU/Memory-Limits in dem Setup für Docker-Compose ergänzt

Setup für Docker von COMBINED auf ISOLATED (mit einem Controller) umgestellt

Setup für Docker Compose auf Image `apache/kafka` und KRAFT umgestellt

Fehler im Docker-Setup: log.interval.check.retention.ms war uneinheitlich

Schema-Registry & Connect aus dem Setup für die Grundlagen entfernt

Zoonavigator aus dem Docker-Setup entfernt

Kafka-Images auf 7.8.0 aktualisiert

`log.retention.check.interval.ms` auf 10 Sekunden gesetzt

``version``-Eintrag in `docker-compose.yml` entfernt

"Final Newline" in `.editorconfig` gefordert (scheint vim zu entsprechen)

`.gitignore` und `.editorconfig` hinzugefügt

Schreibweise des CLI-Kommandos für Docker-Compose korrigiert

Upgrade der verwendeten Kafka-Images auf 7.7.1

ZooNavigator in den Demo-Stack aufgenommen

`README.sh` bricht ab, wenn `setup` nicht erfolgreich ist!

Start von Service `setup` startet auch `cli`

Der Service `setup` wartet bereits auf den Cluster

Grace-Period für Broker und cli/setup gesetzt

Schönere YAML-Syntax für `setup`-Service

Services `schema-registry` und `connect` hinzugefügt

Hilfs-Services `setup` überarbeitet

Volumes für die Log-/Config-Daten und Zookeeper hinzugefügt

Setup zurück auf Confluent (Version 7.5.1) mit Zookeeper umestellt

AKHQ auf einen eindeutigeren Port verlegt

Automatisches entfernen von Orphans beim Start

Docker-Setup in das Unterverzeichnis `docker` verschoben

Docker-Setup auf `bitnami/kafka:3.4` aktualisiert und vereinfacht

* Die Konfiguration musste an (undokumentierte?!) Änderungen in der
  version 3.4 von `bitnami/kafka` angepasst werden.
* Die drei Broker spielen jetzt gleichzeitig Controller. D.h., der
  Service `kafka-0`, der explizit Controller gespielt hat, fällt weg.

Bedienbarkeit des Setups verbessert

* Setup starten mit `docker-compose up -t0 -d cli`
** Dabei wird _nicht_ automatisch das Topic `test` neu angelegt
** D.h., die Daten gehen nicht unbeabsichtigt verloren, wenn man mit
   `up -d` prüft, ob noc alles läuft!
* Das Topic `test` kan mit `docker-compose restart -t0 setup` explizit
  gelöscht und neu angelegt (aka geleert) werden.

`docker-compose up setup` startet auch die cli

AKHQ zu dem Basis-Setup hinzugefügt

Compose-Setup auf bitnami mit KRAFT umgestellt

* Setup aus Unterschied zu `spring-consumer--json--adder` übernommen.
* Auch das `README.sh` entsprechend angepasst.

Für ordering-Übung werden zwei Partitionen benötigt!

Setup mit 3 Broker und Topic-Erzeugung mit Setup für acks-Übung

Merge der Upgrades für Confluent/Spring-Boot (Branch 'first-contact')

Upgrade von Spring Boot und den Confluent-Kafka-Images

* Upgrade der Kafk-Images von Confluent 7.0.2 auf 7.1.3
** Unterstützt Kafka 3.1.x (siehe https://docs.confluent.io/platform/current/installation/versions-interoperability.html[Versions-Matrix])
* Upgrade für Spring Boot von 2.6.5 auf 2.7.2
** Enthält Kafka: 3.1.1
** Enthält Spring Kafka: 2.8.8

Setup aus der Intro-Übung übernommen

Setup "entkernt": Implementierungen entfernt

Upgrade der Images von Confluent 6.2.0 auf 7.0.2

README.sh verwendet den cli-Service für Kommandos

Fälschlich hartkodiertes Topic gegen Variable getauscht

Code reorganisiert, um Änderungen vergleichbarer zu machen

Upgrade für Spring Boot 2.6.0 -> 2.6.5

* Kafka: 3.0.1
* Spring Kafka: 2.8.4

First Contact: Simple Producer & Consumer