Das Quarkus-Projekt aufsetzen

Das Quarkus-Projekt aufsetzen

0:00 Jetzt wird es konkret. In diesem Modul entsteht das Projekt, das uns die restlichen fünfzehn Module begleitet. Ein neues Quarkus-Projekt ist in zwei Minuten erzeugt — das ist nicht der schwierige Teil. Interessant wird es dort, wo ein Handgriff, den Sie aus Spring Boot im Schlaf beherrschen, plötzlich ins Leere greift: bei der Konfigurationsdatei, bei den Profilen, bei der Frage, was eigentlich ein Starter ist und was eine Extension.

0:25 Genau diese Stellen sehen wir uns an, damit der Umstieg nicht an Kleinigkeiten hängen bleibt.

Das Quarkus-Projekt aufsetzen

0:31 Wir sind noch am ersten Tag und damit im Fundament. Nach diesem Modul haben Sie ein lauffähiges Projekt, kennen die wichtigsten Unterschiede in der Projektstruktur und haben den Dev Mode einmal in Aktion gesehen. Danach folgen die drei Bausteine, die Sie täglich benutzen: Dependency Injection, REST und Konfiguration.

Projekt erzeugen und Extensions wählen

0:50 Beginnen wir mit dem Anlegen. Es gibt mehrere Wege, und alle führen zum selben Ergebnis — wichtiger als der Weg ist, was dabei über Extensions entschieden wird. Eine Quarkus-Anwendung besteht aus einem kleinen Kern und den Extensions, die Sie auswählen. Die Platform BOM legt fest, welche Versionen zusammenpassen — sie ist gewissermaßen die Stückliste, die verhindert, dass Sie Teile aus verschiedenen Baureihen kombinieren.

1:15 Von Spring Boot kennen Sie das Prinzip als Starter samt Dependency Management. Der Unterschied liegt darin, was eine Extension zusätzlich mitbringt: Sie wirkt nicht nur als Abhängigkeitsbündel, sondern greift in den Build ein. Was das bedeutet, haben wir im letzten Modul gesehen. Drei Befehle, mehr braucht es nicht. Der erste erzeugt das Projekt mit einer Extension für REST samt JSON.

1:38 Der zweite und dritte rüsten nach — und das ist der Punkt, auf den es ankommt: Extensions fügen Sie jederzeit hinzu, Sie müssen also nicht am Anfang alles vorhersehen. Der letzte Befehl zeigt, was überhaupt installierbar ist; das ist der schnellste Weg, um zu prüfen, ob es für eine Spring-Bibliothek ein Gegenstück gibt.

1:57 Wer keine CLI installieren möchte, bekommt dasselbe Projekt über das Maven-Plugin — die Version darin ist die Platform-Version. Der Unterschied klingt akademisch, hat aber vier sehr praktische Folgen. Eine Extension bringt Build Steps mit, die zur Bauzeit Bytecode erzeugen — das ist die Grundlage für kurze Startzeiten. Wer stattdessen eine Bibliothek direkt als Abhängigkeit einbindet, bekommt genau das nicht: keine Native-Unterstützung, keine Dev Services, keine Integration in die Dev UI.

2:27 Die Platform BOM hält die Versionen konsistent, statt dass Sie sie einzeln pflegen. Und weil sich Extensions jederzeit nachrüsten lassen, ist die Entscheidung am Projektanfang nie endgültig. Suchen Sie also erst nach der Extension, bevor Sie zur Bibliothek greifen. Vier Fallen, die wenig kosten, wenn man sie kennt. Erstens greift man aus Gewohnheit zur Bibliothek, obwohl es die passende Extension gibt.

2:52 Zweitens werden Versionen gegen die BOM festgenagelt — das funktioniert genau bis zum nächsten Plattform-Update. Drittens wächst die Extension-Liste im Laufe eines Projekts und wird nie ausgemistet, obwohl jede zusätzliche Extension Buildzeit kostet. Und viertens ein banaler, aber teurer Punkt: Der Artefaktname wandert später in Imagenamen, Deploymentnamen und Pipelines.

3:15 Überlegen Sie ihn sich einmal richtig, statt ihn in drei Wochen umzubenennen.

Projektstruktur und Konfiguration

3:21 Sehen wir uns an, was das erzeugte Projekt enthält — und wo die Dateien liegen, die Sie aus Spring Boot kennen, hier aber anders heißen. Die Struktur wird niemanden überraschen: die übliche Maven-Aufteilung, Quellcode und Tests an den gewohnten Stellen. Drei Dinge lohnen einen Blick. Die Konfiguration liegt in einer Properties-Datei statt in YAML. Unter dem Docker-Ordner liegen bereits vorbereitete Dockerfiles — schauen Sie hinein, bevor Sie eigene schreiben.

3:48 Und im Dev Mode begrüßt Sie eine Landingpage, die anzeigt, welche Extensions aktiv sind. Das klingt nach Kosmetik, ist aber im Alltag der schnellste Weg zu der Frage: Ist das, was ich hinzugefügt habe, überhaupt angekommen? Diese Tabelle ist bewusst klein gehalten, denn sie soll kein Wörterbuch sein, sondern ein Muster zeigen: Die Konzepte sind identisch, die Namen sind es nicht.

4:11 Aus dem aktiven Profil wird ein anderer Schlüssel, aus typisierter Konfiguration eine andere Annotation, aus dem Web-Starter eine REST-Extension. Sparen Sie sich das Auswendiglernen — wichtig ist nur, dass Sie beim Übertragen nicht blind suchen und ersetzen, sondern jeweils in die Referenz sehen. Und ja: YAML lässt sich nachrüsten. Der Standardweg sind aber Properties, und im Team ist es meist klüger, dem Standardweg zu folgen.

4:37 Hier sehen Sie das Muster, das Sie ab jetzt ständig brauchen: Ein vorangestelltes Prozentzeichen markiert den Profilnamen, alles andere bleibt wie gewohnt. Darunter ein eigener fachlicher Schlüssel — achten Sie darauf, eigene Schlüssel nicht unter dem Quarkus-Namensraum abzulegen. Die letzte Zeile ist die wichtigste des ganzen Moduls: Eine Umgebungsvariable sticht die Datei.

4:58 Das ist genau das Verhalten, das Sie im Container brauchen — und genau das Verhalten, das lokal zu einer halben Stunde Fehlersuche führt, wenn jemand vergessen hat, dass die Variable noch in seiner Shell steht. Der erste Punkt trifft fast jeden: Die YAML-Struktur wird eins zu eins übernommen, obwohl die Schlüssel anders heißen — das kompiliert, tut aber nichts.

5:19 Der zweite ist der Klassiker aus der vorigen Folie: Ein gesetztes Profil wird von einer Umgebungsvariablen still überstimmt. Der dritte klingt banal: Die mitgelieferten Dockerfiles werden übersehen und später von Hand neu erfunden. Und der vierte rächt sich beim nächsten Quarkus-Update, wenn ein selbst gewählter Schlüssel plötzlich mit einem Framework-Schlüssel kollidiert.

5:40 Nutzen Sie einen eigenen Namensraum, etwa den Namen Ihrer Anwendung.

Dev Mode, Dev UI und Continuous Testing

5:44 Kommen wir zu dem Teil, der im Alltag am meisten verändert. Nicht die Startzeit in Produktion, sondern die Rückmeldezeit während der Entwicklung. Der Dev Mode lädt geänderte Dateien beim nächsten Aufruf neu — ohne Neustart. Das Bild: Sie müssen nicht das Haus verlassen und neu betreten, um zu sehen, dass jemand ein Bild aufgehängt hat.

6:04 Dazu kommt die Dev UI im Browser, die Extensions, Konfiguration und Endpunkte zeigt, und Continuous Testing, das betroffene Tests bei jeder Änderung mitlaufen lässt. Die Wirkung ist schwer zu übertreiben: Zwischen Ihrer Änderung und der Erkenntnis, ob sie richtig war, liegen Sekunden statt einer Minute Neustart. Diese fünf Schritte sind keine Anleitung zum Auswendiglernen, sondern eine Empfehlung für den ersten Nachmittag: Machen Sie diese Schleife einmal bewusst.

6:32 Starten, aufrufen, ändern, sehen. Dann Continuous Testing einschalten und beobachten, welche Tests von selbst anspringen. Und wenn Sie ohnehin dabei sind, hängen Sie einmal den Debugger an — der Port ist bereits offen, Sie müssen nichts konfigurieren. Wer diese Schleife einmal gefühlt hat, versteht, warum in der Quarkus-Dokumentation so oft von Developer Joy die Rede ist.

6:55 Fairerweise: Auch Spring Boot hat Werkzeuge für schnelles Neuladen, und es gibt Entwicklungsumgebungen, die viel davon abnehmen. Der Unterschied liegt darin, dass hier alles ohne Zusatzkonfiguration zusammenspielt — Neuladen, Tests, Konfigurationsübersicht und die automatisch gestarteten Infrastrukturdienste. Der Neustart verschwindet als Denkpause, und Tests werden vom Termin zum Hintergrundgeräusch.

7:18 Das ist kein Argument für eine Migration; niemand migriert eine Produktivanwendung wegen des Entwicklungskomforts. Aber es ist ein ehrlicher Teil der Rechnung, wenn ein Team dauerhaft auf dieser Plattform arbeitet. Vier Dinge, die im Dev Mode irritieren. Erstens: Manche Änderung braucht doch einen Neustart oder sogar einen neuen Build — nämlich dann, wenn sie eine Build-Time-Property betrifft.

7:41 Zweitens wird Continuous Testing gern abgeschaltet, weil eine einzelne langsame Testklasse nervt; besser ist, diese Klasse zu markieren, statt die ganze Rückmeldung aufzugeben. Drittens ist der Standardport belegt, und die Fehlermeldung wird dem Framework angelastet. Und viertens, wichtig für später: Im Dev Mode gilt automatisch das Entwicklungsprofil.

8:02 Messwerte aus diesem Modus taugen für gar nichts.

Übung

8:06 Jetzt sind Sie dran. Wir legen das Zielprojekt für Pfandkreis an — noch ohne Fachlogik, aber mit allem, was es zum Starten und Konfigurieren braucht. Das Ziel dieser Übung ist bewusst bescheiden: Das Projekt soll starten und konfiguriert sein, mehr nicht. Es soll noch nichts können. Genau darin liegt der Wert — Sie trennen das Aufsetzen vom Migrieren und haben damit eine saubere Ausgangsbasis.

8:29 Erfolgreich sind Sie, wenn der Dev Mode läuft, die Landingpage Ihre Extensions zeigt und mindestens fünf Konfigurationsschlüssel aus dem bestehenden Dienst übertragen sind. Wer schneller ist, schaltet Continuous Testing ein und lässt den mitgelieferten Testrumpf mitlaufen. Die Reihenfolge ist Absicht. Erst das Projekt mit sauberen Namen, dann die Extensions für REST, Persistence und Datenbanktreiber.

8:53 Dann die Konfiguration übertragen — und dabei ruhig langsam vorgehen, denn hier entstehen die Fehler, die später niemand mehr findet. Danach die drei Profile anlegen, und zwar alle drei, nicht nur das, mit dem Sie gerade arbeiten. Zum Schluss der Dev Mode und ein Rundgang durch die Dev UI. Nehmen Sie sich diese letzten fünf Minuten wirklich; sie ersparen Ihnen später viel Suchen.

9:16 Vier Dinge, auf die Sie in dieser Übung achten sollten. Fügen Sie nicht alle Extensions auf Verdacht hinzu — jede verlängert jeden Build, den Sie ab heute machen. Lassen Sie beim Übertragen keine Zugangsdaten in der Konfigurationsdatei landen; auch nicht kurz, auch nicht als Platzhalter mit echtem Wert. Legen Sie die Profile nicht nur an, sondern starten Sie jedes einmal — ein Profil, das nie gestartet wurde, ist nur eine Vermutung.

9:42 Und bleiben Sie beim einmal gewählten Artefaktnamen. Er zieht später Image- und Deploymentnamen hinter sich her.