Suche
EMF-Support für Che

Eclipse Che Tutorial: Schritt für Schritt zum eigenen Plug-in

Jonas Helming, Maximilian Kögel, Matthias Hansen

Eclipse Che ist eines der spannendsten neuen Projekte bei Eclipse. Dass es sich bei Che um mehr als eine reine Browser IDE handelt, zeigt diese Tutorial-Reihe von Jonas Helming, Maximilian Kögel und Matthias Hansen. Erfahren Sie, wie man Eclipse Che Schritt für Schritt um ein neues Plug-in erweitert.

EMF-Support für Che

Das erste öffentliche Release von Eclipse Che wurde auf der EclipseCon North America 2016 vorgestellt. Beinahe plötzlich gab es damit eine neue Cloud-basierte IDE im Eclipse-Ökosystem. Auf den ersten Blick handelt es sich “nur” um eine browserbasierte IDE.

Eclipse Che

Eclipse Che

Allerdings macht sich Che mit einem besonderen Feature weit mehr interessant: Sharable Workspaces. „Workspace“ bedeutet in Che der Quellcode eines Projekts PLUS die Runtime, um diesen kompilieren, debuggen und ausführen zu können. Traditionell sind Workspaces ein lokales Konzept, bei dem Entwickler die Sources herunterladen und anschließend etliche Tools installieren müssen, um schlussendlich mit dem Code arbeiten zu können. Che nutzt Docker-Container, um die Workspace-Runtimes, die auf Servern gehostet werden, anzubieten. Das macht es einfach, den Workspace mit anderen Entwicklern zu teilen und vermeidet somit komplizierte Setups und zusätzlichen Aufwand bei neuen Projektteilnehmern. Wenn Sie mehr über Che erfahren möchten besuchen sie bitte die Homepage des Projekts.

Wir bei EclipseSource sind natürlich an dieser neuen Technologie interessiert. Ein Teil unseres Interesses bezieht sich darauf, wie leistungsstark Eclipse Che im Vergleich zu der vorhandenen Eclipse IDE ist. Als Technology Provider geht es uns allerdings noch mehr darum, das neue Framework zu erweitern und anzupassen und damit noch fehlende Features einbauen zu können. Insbesondere interessiert uns, ob wir existierende Eclipse-Technologien in der Cloud IDE wiederverwenden können.

Darum haben wir es sofort selbst ausprobiert: die Erweiterung von Che um ein neues Plug-in. Unser Ziel ist, die Plattform kennen zu lernen, Erfahrung zu sammeln und Feedback zu liefern. Um dies zu erreichen, wollen wir einen echten Use-Case bearbeiten. Wir haben dafür ein Feature gewählt, mit dem wir besonders vertraut sind, das allerdings noch nicht in Che vorhanden ist: das Eclipse Modeling Framework (EMF) Tooling samt Codegenerierung. Falls Sie EMF nicht kennen: Es handelt sich dabei um ein sehr pragmatisches Modellierungs-Framework zur Generierung von Java-Entity-Klassen. Kurz gesagt: Es ist wie Java Beans, aber leistungsfähiger und mit weniger manueller Arbeit. Wenn Sie sich für EMF interessieren, finden sie hier ein Basis-Tutorial.

Wir wollen unsere Erfahrungen und die gefundenen technischen Lösungen bei der Entwicklung von EMF-Support in Che in einer Serie mit Ihnen teilen. Das folgende Diagramm zeigt unseren Use-Case:

Teilen wir den Use-Case in verschiedene Schritte auf:

  1. Create Modeling Project: Als ersten Schritt wollen wir ein „Modeling Project“ erstellen können – ein Projekt mit allen typischen Artefakten eines Ecore-Bundles. Vor allem bedeutet das, eine .ecore-Datei für das Model und eine .genmodel-Datei zur Codegenerierung zu erzeugen. Wir müssen Che also derart erweitern, dass es ein Template zur Neuinstanziierung oder idealerweise einen „New Project“-Assistenten enthält. Im ersten Schritt könnten wir ein bestehendes Template-Projekt verwenden, da wir dadruch bereits in der Lage wären, an den nachfolgenden Anforderungen zu arbeiten.
  2. Edit Ecore and GenModel: Natürlich wollen wir beide Artefakte modifizieren, also brauchen wir einen Editor, der das ermöglicht. Im einfachsten Fall ist das ein textbasierter Editor, der mit den neuen Dateitypen .ecore und .genmodel umgehen kann.
  3. Generate Code: Da es das Ziel von EMF ist, aus Ecore-Models Code zu generieren, wollen wir diese Generierung auch in Che unterstützen. Da wir den EMF-Codegenerator allerdings nicht neu implementieren wollen, müssen wir einen Weg finden, den vorhandenen Generator in Che zu integrieren. Schlussendlich brauchen wir eine Aktion, die die Codegenerierung in der Che IDE auslöst.
  4. Form-basierter Editor für Ecore und Genmodel: Letztendlich wollen wir den gleichen Komfort für die Bearbeitung von Ecore- und GenModels erreichen, wie ihn die Eclipse IDE bietet: Ein Tree-/Formular-basierten Editor.

Die gute Nachricht ist, dass all dies in Che möglich ist und wir bereits einen Prototyp implementieren konnten, der alle genannten Anforderungen erfüllt. Wenn Sie sich den dazugehörigen Code anschauen möchten, können Sie das in diesem Repository tun.

Noch interessanter ist allerdings, wie wir diesen Prototyp gebaut haben. Wir werden deshalb alle Entwicklungsschritte in dieser Serie beschreiben. Die verfeinerten Details der Umsetzung kommen später zur Sprache, wenn Sie Eclipse Che etwas näher kennengelernt haben.

In diesem ersten Teil geht es nun darum, wie man Che einen benutzerdefinierten „Modeling Workspace“ inklusive Template-Projekt hinzufügen kann. Legen wir los!

Tag 1: Eclipse Che lokal ausführen und existierende EMF-Projekte importieren

Bevor wir damit beginnen, Eclipse Che zu erweitern, starten wir es zunächst lokal und sehen uns an, welche Funktionen von Haus aus unterstützt werden. Zum Start wählen wir den einfachsten Weg, um ein bestehendes „Modeling Project“ in einen Che-Workspace zu bringen. Das Modeling Project wird noch nicht von Che erstellt, sondern von einer Eclipse Modeling Tools IDE. Durch den Import dieses bestehenden Projekts können wir testen, welche Features bereits in Che vorhanden sind und welche wir später erweitern müssen.

Als Template-Projekt werden wir das bestehende „Make it happen!“-Modell verwenden (mehr Details dazu hier). Dieses Beispielmodell wird mit jeder Eclipse-Modeling-Tools-IDE ausgeliefert (die Desktop IDE dabei nicht mit dem hier verwendeten Eclipse Che verwechseln!). Instanziiert wird das Modell per „New => Example => Make it happen: Example Model“. Das Template-Projekt enthält bereits generierten Code. Da wir den Code später in Che selbst generieren wollen, haben wir eine Version des „Make it happen!“-Modells ohne generierten Code („makeinhappen_blank“) erstellt, die auf GitHub verfügbar ist.

Als Vorbereitung haben wir Che, wie hier beschrieben, heruntergeladen und ausgeführt. Wir werden also erst einmal die Standard-Version ohne Extensions verwenden.

Beim Start von Che in Ihrem Browser wird zuerst das „Dashboard“ angezeigt. Es ermöglicht Ihnen, zunächst Workspaces zu erstellen, aber noch keine Projekte. Che startet eine separate Runtime für jeden Workspace. Jeder davon kann als einzelner Docker-Container oder als Gruppe von Containern mit einem zusammengesetzten Recepie definiert werden. Der Standard ist allerdings ein Container pro Workspace.

Der Quellcode und die entsprechende Runtime (d.h. ein JDK oder jedes andere beliebige Tool) sind in diesem Container enthalten, wodurch diese leicht geshared werden können. Wie man im Dashboard sehen kann, gibt es eine Vielzahl an vordefinierten Workspace Vorlagen zur Auswahl (auch Stacks genannt). Der „Java“-Stack dient als gute Anfangsbasis.

Nachdem wir einen Workspace ausgewählt haben, wird dieser von Che gestartet. Technisch gesehen ist das, wie erwähnt, ein Docker-Container. Das Konzept ähnelt einer Server-seitigen virtuellen Maschine, in der wir dann tatsächlich entwickeln.

Nach dem Start des Workspaces wird die mit dem Workspace verbundene Browser-IDE angezeigt. Aktuell ist dieser leer. Lassen Sie uns also ein bestehendes Modeling-Project in unseren neuen Workspace bringen.

Gehen Sie zum Import eines Projekts auf „Workspace => Import Project“. Per Default wird dafür ein Git-Repository verwendet – eine Standardeinstellung, die wir auch in unserem Beispiel nutzen wollen. Alles, was getan werden muss, ist die Repository-URL zu kopieren und auf „Import“ zu klicken:

Nun, da wir ein voll konfiguriertes Template-Projekt in unserem Workspace haben, können wir einen Blick auf die existierenden Artefakte werfen. Da es noch keine spezifischen Editoren gibt, werden alle Dateien als Plain-Text interpretiert. Diesen können wir allerdings öffnen und bearbeiten:

Natürlich ist die Arbeit mit Plain-XML nicht hinreichend – später in dieser Serie werden wir uns mit der Erstellung von benutzerdefinierten Editoren beschäftigen. Interessant ist ein Blick auf den zugrunde liegenden Workspace. Das Terminal im unteren Bereich der Che IDE bietet uns hierbei direkten Zugriff. Wenn wir also

vi /projects/makeithappen/org.eclipse.emf.ecp.makeithappen.model/model/task.ecore

ausführen, können wir unser Ecore auch in der Konsole anzeigen lassen:

Konkret bedeutet das, dass jedes kommandozeilenbasierte Tool Zugriff auf die Artefakte unseres Projekts hat. Das ist ein interessanter Erweiterungsmechanismus, auf den wir später in unserem Projekt zurückkommen werden.

Da wir nun eine einfache und reproduzierbare Möglichkeit haben, Template-Projekte zu Testzwecken zu erstellen, können wir anfangen, die nächsten Anforderungen der EMF-Unterstützung in Che zu betrachten. Einleuchtend wäre als nächstes einen Projekt-Wizard, ein benutzerdefiniertes Projekt oder einen maßgeschneiderten Editor für Ecore zu erstellen. Im nächsten Teil dieser Serie werden wir uns dennoch zunächst der Codegenerierung widmen. Dies dient vor allem der Risikominimierung: Wir sind überzeugt, dass es möglich ist, unsere eigenen UI-Erweiterungen für die Che IDE zu erstellen.

Für die Codegenerierung wollen wir jedoch den bestehenden Codegenerator aus EMF benutzen. Gibt es also einen Weg, existierende Eclipse-Features ohne viel Aufwand in Che zu integrieren? Bleiben Sie dran für den nächsten Teil der Serie!

Geschrieben von
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
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.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.