Читать книгу Spring Boot - Mark Heckler - Страница 24

Falls Sie sich am liebsten auf der Kommandozeile herumtreiben oder die Projekterzeugung irgendwann einmal per Skript erledigen wollen, ist das Spring Boot Command Line Interface (CLI) genau das Richtige für Sie. Das Spring Boot CLI besitzt viele erstaunliche Fähigkeiten, doch zunächst einmal wollen wir uns auf die Erzeugung eines neuen Boot-Projekts beschränken.

Das Spring Boot CLI installieren

Am einfachsten lässt sich das Spring Boot CLI über SDKMAN! installieren – genau wie Ihr JDK, die Kotlin-Dienstprogramme und mehr. Sie können im Terminal-Fenster

sdk list

ausführen, um die Pakete zu sehen, die für die Installation zur Verfügung stehen; Abbildung 2-5 zeigt die Darstellung im Spring Boot CLI. Anschließend führen Sie

sdk list springboot

aus, um die verfügbaren Versionen des Spring Boot CLI zu sehen. Die neueste (aktuelle) Version installieren Sie mit

sdk install springboot

Falls Sie mit dem SDKMAN!-Befehl sdk install <tool> <versionsidentifikator> keine spezielle Versionsangabe machen, installiert SDKMAN! üblicherweise die neueste empfohlene Produktionsversion der Sprache/des Werkzeugs. Das kann für die verschiedenen unterstützten Pakete unterschiedliche Dinge bedeuten; so wird z.B. die neueste Long-Term-Support-(LTS-)Version von Java installiert und nicht eine neuere (Nicht-LTS-)Version, die vielleicht vorhanden ist. Das liegt daran, dass alle sechs Monate eine neue nummerierte Version von Java veröffentlicht und regelmäßig eine Version zur LTS-Version erklärt wird – was bedeutet, dass es oft eine oder mehrere neuere Versionen gibt, die jeweils offiziell nur für sechs Monate unterstützt werden (zum Ausprobieren und Testen von Funktionen oder vielleicht sogar für Produktions-Deployments), während eine bestimmte LTS-Version vollständig unterstützt wird, also Updates und Bug-Fixes erfährt.

Diese Anmerkung ist sehr allgemein, und es kann Abweichungen zwischen den einzelnen JDK-Anbietern geben. Die meisten halten sich allerdings mehr oder weniger an die üblichen Vereinbarungen. Den Einzelheiten wurden schon ganze Talks gewidmet, allerdings ist das für unsere Zwecke hier nicht von Belang.

Abbildung 2-5: Das Spring Boot CLI auf SDKMAN!

Nach dem Installieren des Spring Boot CLI können Sie mit dem folgenden Befehl das gleiche Projekt erzeugen wie mit dem Initializr:

spring init

Um das gezippte Projekt in einem Verzeichnis namens demo zu entpacken, führen Sie diesen Befehl aus:

unzip demo.zip -d demo

Moment mal, wieso ist das so einfach? Die Antwort: Standardwerte. Das Spring CLI verwendet die gleichen Standardeinstellungen wie der Spring Initializr (Maven, Java und so weiter), sodass Sie nur für solche Werte Argumente angeben müssen, die Sie ändern wollen. Legen wir einmal speziell Werte für einige dieser Standardwerte fest (und nutzen einen hilfreichen Dreh für die Extraktion des Projekts), um besser zu sehen, wie das geht:

spring init -a demo -l java --build maven demo

Wir initialisieren auch hier ein Projekt mit dem Spring CLI, geben aber nun die folgenden Argumente vor:

 -a demo (oder --artifactId demo) erlaubt es uns, eine Artefakt-ID für das Projekt anzugeben; wir nennen sie hier »demo«.

 -l java (oder --language java) lässt uns Java, Kotlin oder Groovy1 als primäre Sprache für das Projekt festlegen.

 --build ist das Flag für das Build-System-Argument; gültige Werte sind maven und gradle.

 -x demo verlangt, dass das CLI die resultierende .zip-Projektdatei extrahiert, die vom Initializr zurückgegeben wird; beachten Sie, dass das -x optional ist und dass die Angabe einer Textbezeichnung ohne Erweiterung (wie hier) dankenswerterweise als Verzeichnis interpretiert wird, in dem die extrahierte Datei abgelegt werden soll.

All diese Optionen können Sie sich anschauen, wenn Sie auf der Kommandozeile spring help init ausführen.

Beim Festlegen der Abhängigkeiten werden die Dinge etwas komplizierter. Wie Sie sich vorstellen können, ist die Leichtigkeit einer Auswahl aus dem »Menü«, wie es der Spring Initializr bietet, kaum zu schlagen. Allerdings ist die Flexibilität des Spring CLI wiederum ausgesprochen praktisch, wenn es um einen schnellen Einstieg, um Skripte und um die Erstellung von Pipelines geht.

Und noch etwas: Das CLI greift standardmäßig auf den Initializr zurück, um dessen Fähigkeiten zur Projekterstellung auszunutzen. Das bedeutet, dass es im Prinzip egal ist, über welchen Mechanismus (CLI oder die Initializr-Webseite) Sie Projekte anlegen – sie sind in beiden Fällen identisch. Diese Konsistenz ist absolut entscheidend, wenn direkt die Fähigkeiten des Spring Initializr verwendet werden sollen.

Gelegentlich jedoch kontrolliert eine Organisation sehr genau, welche Abhängigkeiten ihre Entwickler benutzen dürfen, um Projekte zu erstellen. Um ganz ehrlich zu sein, macht mich eine solche Herangehensweise ziemlich traurig. Sie wirkt restriktiv und behindert die Agilität der Organisation sowie ihre Fähigkeit, auf die Benutzer/den Markt reagieren zu können. Wenn Sie in einer solchen Organisation sind, erschwert es Ihnen einfach nur Ihre Arbeit.

Es ist allerdings in einem solchen Fall möglich, Ihren eigenen Projektgenerator herzustellen (sogar das Repository für den Spring Initializr zu klonen) und diesen direkt über die resultierende Webseite zu benutzen … oder nur den REST-API-Teil aufzugreifen und diesen vom Spring CLI aus zu verwenden. Fügen Sie dazu einfach diesen Parameter zu den bereits gezeigten Befehlen hinzu (Sie müssen natürlich Ihre eigene URL einsetzen):

--target https://insert.your.url.here.org