Suche
EMF-Support für Che

Eclipse Che Tutorial: Tag 4 – Building Che

Maximilian Kögel, Jonas Helming

In dieser Artikel-Serie beschreiben wir unsere Erfahrung mit der Entwicklung von Erweiterungen (Plug-ins) für Eclipse Che. Als durchgängiges Beispiel dient eine erste Version für EMF-Support in Che, welche wir prototypisch entwickelt haben.

Der erste Artikel beschäftigte sich mit unseren Zielen. In anderen vorangegangenen Posts haben wir den Support für Codegeneration und die Erstellung eines Custom-Stacks beschrieben. Zusammen zeigen diese beiden Teile bereits, wie sich die EMF Codegeneration in Che nutzen lässt.

Bisher haben wir noch keinen Code geschrieben, um Che zu erweitern. Wir haben das Konzept von Che-Workspaces (Docker Container) genutzt, um zusätzliche Tools (in unserem Falle Code-Generatoren) zu installieren. Da die Browser-IDE es uns ermöglicht, jeden Befehl im Workspace auf der Kommandozeile auszuführen, bestand bisher noch keine Notwendigkeit, etwas der IDE selbst zu erweitern.

Allerdings gibt es Anforderungen, für deren Realisierung die reine Erweiterung von Workspaces nicht ausreicht. Das ist typischerweise der Fall, wenn die UI der Browser-IDE um neue Features erweitert werden soll oder der Workspace neue APIs anbieten soll.

In diesem Teil unserer Serie nehmen wir eine erste kleine Änderung an der Browser-IDE selbst in Form eines einfachen „Hello World“-Beispiels vor. Das ist ein guter erster Schritt, um die generelle Art und Weise vorzustellen, wie die Che IDE erweitert werden kann. In zukünftigen Artikeln werden wir uns mit komplexeren Erweiterungen beschäftigen.

EclipseSource verfügt über eine jahrelange Erfahrung in der Entwicklung von Extensions für die Eclipse-IDE und von Eclipse-basierten Applikationen. Lassen Sie uns also, bevor wir die Erweiterung von Eclipse Che gehen, unsere Erfahrungen mit der Entwicklung von Extensions für Che aus dem Blickwinkel eines Desktop Eclipse-IDE-Entwickler zusammenfassen. Unser Hauptaugenmerk legen wir dazu auf die offensichtlichsten Gemeinsamkeiten und Unterschiede.

Die Gemeinsamkeiten: Eclipse Che hat eine grundsätzlich erweiterbare und flexible Architektur. Dafür verantwortlich ist im Wesentlichen die Service-Orientierung. Dieses Pattern unterstützt die Erweiterbarkeit auf verschiedene Weisen:

  • Che bietet Services, um beinahe alle Teile der UI erweiterbar aufzubauen. Beispielsweise gibt es einen Service, um Actions zu registrieren, welche in Menüs angezeigt werden. Ein weiterer Service erlaubt es, Dateitypen und deren Editoren zu registrieren.
  • Che bietet Services, um Ressourcen (z.B. Source Files) und die Workspace-Runtime (z.B. um Befehle zu triggern) nutzen zu können. Durch die Verwendung dieser existierenden Features ist es leicht, neue Funktionalitäten hinzuzufügen.
  • Der Che-Server besteht größtenteils aus REST-Services. Durch das Hinzufügen von benutzerdefinierten REST-Services kann damit die Funktionalität des Server komfortabel ausgebaut werden. Benutzerdefinierte Services können somit anschließend von benutzerdefinierten Erweiterungen der Browser-IDE verwendet werden.
  • Schlussendlich definiert Che Service-Interfaces, die von Erweiterungen implementiert werden können, um neue Funktionalitäten anzuliefern. Als Beispiel kann ein Service implementiert werden, der einen benutzerdefinierten Projekt-Typ anbietet.

Die Unterschiede: Derzeit gibt es keinen zur Laufzeit funktionierenden Plug-in-Mechanismus in der Che Browser-IDE, der mit den gewohnten Features der klassischen Eclipse-IDE (a.k.a Update-Sites / p2 Repositories) vergleichbar wäre. Das bedeutet, dass man zur Erweiterung von Che zuerst eine eigene Version bauen und deployen muss, welche die eigene Erweiterung enthält. Technisch betrachtet handelt es sich bei „Plug-ins“ in Che um Maven Modules, die während der Kompilierung zum Build hinzugefügt werden können. Erweiterungen zur Laufzeit gibt es in der Browser-IDE nicht. Die offensichtliche Frage ist: Handelt es sich dabei nicht um einen Rückschritt, wenn man es mit der klassischen Eclipse-IDE vergleicht? Je nach Blickwinkel gibt es auf diese Frage unterschiedliche Antworten:

  • Nein, denn Che unterstützt Erweiterbarkeit zur Laufzeit mit seinem Workspacekonzept. Wenn ein beliebiges Tool oder eine Laufzeitkomponente vermisst wird, kann sie leicht in den Workspace installiert und anschließend mit anderen Entwicklern geteilt werden. Beispielsweise haben wir die EMF-Codegeneration zur Laufzeit nur durch die Erweiterung des Workspaces ermöglicht. In der klassischen Eclipse-IDE muss jeder Entwickler benötigte Plug-ins selbst installieren (zumindest, wenn man Oomph nicht nutzt).
  • Teilweise, da weder die Browser-IDE, noch der Che-Server zur Laufzeit erweitert werden kann – nur der Workspace. Allerdings hat Che ein anderes Deployment-Szenario. Da es sich dabei um eine Client-Server-Applikation handelt, besteht die grundlegende Idee darin, das Setup ein einziges Mal zentral durchzuführen und anschließend mit einer Gruppe Entwickler zu teilen, welche die gleichen Tools benötigen. Das ermöglicht Entwicklern ein sehr schnelles Projektsetup (ähnlich wie Oomph im klassischen Eclipse). Es ermöglicht zudem sogar die Nutzung von unterschiedlichen IDEs im gleichen Workspace. Gleichzeitig bedeutet es allerdings auch mehr Arbeit für die Pflege der Extensions, während die Entwickler es leichter haben.
  • Ja, wir vermissen OSGi-Extension Points und p2-Repositories! Obwohl OSGi und p2 in der Vergangenheit gerne kritisiert wurden, handelt es sich um mächtige Technologien für modulare und erweiterbare Applikationen. In Verbindung mit dem großartigen, von Eclipse zur Verfügung gestellten Tooling zur Entwicklung von Plug-ins, ist es in Eclipse sehr effizient möglich, eigene Erweiterungen zu entwickeln, zu installieren und zu updaten. Dies ist vermutlich einer der Kernfaktoren, die die Entwicklung eines derart großen Tool-Ökosystems rund um Eclipse möglich gemacht haben.

Am Ende kommt es schlicht auf das jeweilige Szenario an. Zudem ist es erwähnenswert, dass es einen generellen Trend gibt, Teile der IDE in serverseitige Abstraktionen auszulagern, sodass sie unabhängig werden. Das Language-Server-Protokoll ist ein gutes Beispiel dafür. In diesem Szenario muss die IDE nur die gelieferten Abstraktionen unterstützen, z.B. LSP. Somit wird clientseitige Erweiterung in Zukunft womöglich weniger wichtig.

Wie dem auch sei – lassen Sie uns Che lokal erweitern und bauen. Der generelle Ablauf dazu ist in folgender Abbildung als Übersicht dargestellt.

Zuerst müssen alle Abhängigkeiten installiert werden. Dass Docker dafür benötigt wird, haben wir bereits erwähnt. Aber darüber hinaus werden eine Reihe weiterer Tools und Einstellungen benötigt, um Che zu bauen.

Für den Start gibt es zwei Möglichkeiten. Wir empfehlen „headless“ zu beginnen und dem Guide „How to clone and build Che“ zu folgen. Falls Sie eine IDE verwenden wollen, empfehlen wir im zweiten Schritt den „Che Workspace Setup Guide“ für einen ausführlichen Überblick.

Wir empfehlen, sich die Zeit zu nehmen und die mitgelieferte Dokumentation sorgfältig zu lesen, da sie nützliche Informationen und viele gute Tipps zur Entwicklung mit Che bieten. Besondere Aufmerksamkeit sollte dabei dem „Super Dev Mode“ gewidmet werden, da er für GWT-Applikationen ein „Hot Code Replacement“ erlaubt und damit die Turnaround-Time bei der Arbeit an der Browser-IDE stark reduziert.

Weiterhin gibt es die Möglichkeit, Che innerhalb einer vordefinierten Docker-Umgebung zu bauen, was einem die Mühe, diese selbst aufzusetzen, erspart. Letztlich wird das Bauen von Che einige Zeit in Anspruch nehmen, selbst wenn es auf einer schnellen Maschine ausgeführt wird. Eine nähere Beschäftigung mit diesen alternativen Optionen wird deshalb empfohlen und im Detail hier beschrieben.

Der Buildprozess erzeugt eine Anzahl an Artefakten; in Che-Terminologie sogenannten „Assemblies“. Sie werden im „Assembly“-Unterordner abgelegt. Um sie zu identifizieren, lohnt sich ein Vergleich der Ordner mit den logischen Che-Komponenten des Architekturschemas.

Nachdem der Build ausgeführt wurde, kann Che auf der lokalen Machine gestartet werden. Dazu navigiert man in den Ordner assembly/assembly-main/target/[che-version]/[che-version] und führt dort den Befehl bin/che.sh start aus. Die Konsole sollte den Service-Start bestätigen, danach lässt sich localhost:8080 im Browser öffnen. Wenn alles funktoniert hat, sollte sich das Che-Dashboard öffnen.

Nach einem ersten erfolgreiche Build, wollen wir nun eine einfache Änderung vornehmen. Ein Beispiel wäre das Hinzufügen eines Projekt-Templates zur Browser-IDE. Projekt-Templates können von jedem User der IDE instanziert werden. Für den EMF-Support in Che wäre es nützlich, ein Beispiel-EMF-Projekt als Template zur Verfügung zu haben. Im zweiten Teil dieser Artikelserie haben wir bereits ein solches Template aus einem Git Repository importiert. Dieses werden wir nun als Template fix zu unserem benutzerdefinierten Assembly hinzufügen.

Projekt-Templates sind im Prinzip Pointer zu existierenden Git Repositories. Das hält die Templates wartbar, ohne dass die IDE selbst neu ausgebracht werden müsste. Templates werden in der folgenden Datei maintained:

1 ide/che-core-ide-templates/src/main/resources/samples.json

Lassen Sie uns das folgende Snippet zu der Datei hinzufügen:

{
   "name": "emfforms-makeithappen-blank",
   "displayName": "emfforms-makeithappen-blank",
   "path": "/",
   "description": "EMFForms, make it happen!",
   "projectType": "java",
   "mixins": [],
   "attributes": {
     "language": [
       "java"
     ]
   },
   "modules": [],
   "problems": [],
   "source": {
     "type": "git",
     "location": "https://github.com/eclipsesource/emfforms-makeithappen-blank",
     "parameters": {}
   },
   "commands": [],
   "links": [],
   "category": "Samples",
   "tags": [
     "maven",
     "java"
   ]
 }

Im Anschluss müssen wir die aktuell laufende Che-Instanz stoppen, indem wir bin/che.sh stop ausführen, Che neu builden und dann wieder mittels bin/che.sh start starten. Als Ergebnis ist das neue Projekt-Template in der Che IDE zwischen den bereits existierenden verfügbar.

Natürlich war das eine sehr einfache Änderung – es musste nicht einmal Code geschrieben werden. Allerdings ist das Setup nun bereit, komplexere Änderungen durchzuführen und eigenen Code gegen die Che APIs zu schreiben. In unserem Beispiel haben wir lediglich eine Che-Konfigurationsdatei angepasst, um unser eigenes Projekt-Template hinzuzufügen. Diese Art Extension wird für gewöhnlich durch den Aufruf von Services bearbeitet, was es ermöglicht, die Basiskonfiguration von Che auch über eigene Module zu erweitern, ohne Che selbst zu modifizieren. Wir werden diese saubere Lösung der Erweiterung später in dieser Artikel-Serie beschreiben.

Typischerweise werden Che-Extensions als separate Maven-Modulen (d.h. Plug-ins) entwickelt. Konzeptionell ähnelt das der Entwicklung von Plug-ins im klassischen Eclipse. Die eigene Codebase ist dadurch vom Che-Kern separiert. Im nächsten Teil unserer Blog-Serie werden wir dies detailliert beschreiben. Als Beispiel werden wir ein Plug-in erstellen, das einen neuen Dateityp („.ecore“) registriert – einschließlich eines Icons.

Wenn Sie mehr über den EMF-Prototyp erfahren, sich aktiv einbringen bzw. die weitere Entwicklung unterstützen möchten, kontaktieren Sie uns gerne.

Geschrieben von
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: