Fix und Fertig – Eclipse automatisiert aufsetzen


de KaffeeKlatsch Eclipse

Erschienen im KaffeeKlatsch 12/2017


Ein neuer Kollege kommt ins Projekt. Wie lange dauert es, bis er seine Entwicklungsumgebung vollständig und korrekt aufgesetzt, alle nötigen Projekte importiert hat und nun erste Codeänderung ausprobieren oder einfach nur Debuggen kann? Dasselbe Problem haben viele umfangreichere Open-Source Projekte – ein neuer Contributor muss hier oft eine längere Textdatei mit allerlei Einstellungen abarbeiten. Aber: Es geht auch anders!

Der Eclipse Installer “Oomph”1 kann eine vollständig neue IDE mit zusätzlichen Plugins installieren, konfigurieren, ein Git Repository klonen, Projekte importieren und dazwischen auch individuelle Build-Schritte ausführen. Unter anderen.

Oomph beschränkt sich dabei nicht nur auf die erste Installation, sondern auch auf das “Instandhalten” der IDE. Auf diesen Aspekt geht dieser Artikel jedoch nicht ein, nur auf das einmalige Aufsetzen eines kleinen Projektes mit teilweise generiertem Code. Das Projekt und das schrittweise aufgebaute Setup finden Sie im Github Repository2.

Download

Zuerst lädt man auf eclipse.org den Installer direkt über den “Download” Button herunter, packt gegebenenfalls das Archiv aus und startet die Anwendung eclipse-inst.

Normalerweise startet der Installer im “Simple Mode”, über das Hamburger-Menü kann man in den “Advanced Mode” umschalten. In beiden Fällen wählt man zuerst eine passende Grund-IDE aus, zum Beispiel “Eclipse IDE for Java Developers” und installiert sie. Im Gegensatz zur traditionellen Eclipse-Installation werden die dafür benötigten Plugins und Features nicht direkt im Installationsverzeichnis gespeichert, sondern in einem globalen “Bundle Pool”. Das heißt die Installation weiterer Eclipse-Instanzen erfolgt ohne neuen Download und belegt weniger Plattenplatz. Nach der Installation startet der Installer die neue IDE. Diese neue IDE enthält schon die notwendigen Plugins für Oomph.

Setup

Im neuen Eclipse legt man ein Projekt oomph-intro-setups und darin über den Wizard “Neu → Oomph → Setup Project Model” eine neue Setup-Datei an, wie im Bild dargestellt (siehe Abbildung 1). Nach dem Fertigstellen des Wizards öffnet man die neue Setup Datei in einer Baum-Ansicht (siehe Abbildung 2).

Abbildung 1
Abbildung 2

Der Baum ist mit folgenden Knoten vorbelegt:

Die Knoten repräsentieren “Tasks”, die der Reihe nach ausgeführt werden, wobei “Compound Tasks” mehrere logisch zusammengehörende Schritte zusammenfassen können.

In den Baum können neue Konten über das Kontext-Menü mit “New Child” bzw. “New Sibling” hinzugefügt werden. Die Details der Knoten werden in der “Properties” View unten festgelegt. Die “Outline”-View (im Bild rechts) enthält neben der erwarteten Struktur auch die sehr nützlichen Abschnitte “Unresolved Variables” und “Resolved Variables”. Ohne diesen Abschnitt ist es schwierig, die Namen passender Platzhalter zu ermitteln.

Für das Beispiel werden zuerst die überflüssigen Knoten gelöscht: “eclipse.target.platform” (Typ Variable Task), “Modular Target” und “Working Set”.

Allerdings fehlt jetzt das Importieren von Projekten. Dafür gibt es verschiedene Arten von Tasks:

Für dieses einfache Beispiel fügt man im Kontext-Menü von “Git Clone Task” mit “New Sibling” einen “Projects Import” Knoten hinzu. Dem neuen Knoten fügt man ein Kind von Typ “Source Locator” hinzu und setzt dessen Properties “Locate Nested Projects” auf true und “Root Folder” auf ${git.clone.myproject.location}.

Diese Setup-Datei kann man schon mal ausprobieren. Dazu startet man den Eclipse-Installer erneut und wechselt über das Hamburger-Menü in den “Advanced Mode” (siehe Abbildung 3). Wie im “Simple Mode” wählt man zuerst wieder ein Eclipse-Produkt als Grundlage aus – also wieder “Eclipse IDE for Java Developers” und klickt auf “Weiter”. Auf der folgenden Seite (siehe Abbildung 4) kann man ein oder mehrere Projekte auswählen, für deren Entwicklung das neue Eclipse aufgesetzt werden soll. Eigene Projekte kann man auf zwei Arten hinzufügen: Das grüne Plus-Symbols erlaubt die Auswahl einer Datei im Dateisystem. Oder man zieht die Setup-Datei aus Eclipse heraus auf einen der Order “Eclipse Projects” oder “Github Projects”. In beiden Fällen erscheint das eigene Setup in einem Zwischenorder “”. Nach dem Auswählen und dem Button “Next” erscheint eine weitere Seite (siehe Abbildung 5), auf der man detailliertere Konfigurationen der ausgewählten Projekte vornehmen kann. Auch hier kann mit “Show all Variables” zwischen zwei Detailstufen gewählt werden. Bei diesen Werten muss im Drop-Down Menü bei “MyProject Github repository” der Eintrag “HTTPS (read only, anonymous)” ausgewählt werden. Nach “Next” und “Finish” beginnt Oomph mit der Installation des ausgewählten Eclipse Produktes und der Setup-Projekte. Oomph installiert die neue IDE in das Verzeichnis myproject-master/eclipse/. Nach dem Starten der neuen IDE startet Oomph das Clonen des Git-Repitory und legt es unter myproject-master/git/ ab. Anschließend importiert es das Projekt in den neuen Workspace myproject-master/ws/.

Abbildung 3
Abbildung 4
Abbildung 5

Für wirklich einfache Projekte kann dieses Setup schon ausreichen. Aber in vielen Fällen muss noch ein Buildsystem wie Maven oder Gradle vorher angestoßen werden, um z.B. Sourcen zu generieren. Im Beispielprojekt wird dies durch ein Ant-File angedeutet, das eine zusätzliche Datei Person.java in den Source-Folder legt. Da diese Datei im Moment noch fehlt, ist der Build rot.

Maven, Ant, Gradle & Co

Beliebige Build-Schritte können in das Setup über einen “Launch” Knoten eingehängt werden. Ein solcher Knoten führt eine Eclipse-Launch Configuration aus. Eine Launch Configuration kapselt den Aufruf eines Java-Programmes, eines Unit-Tests oder eines externen Tools wie zum Beispiel Ant. Im Beispielprojekt sind zwei passende Launch Configurations im Verzeichnis launchers eingecheckt: generate-source und clean.

Beim Einhängen des ersten “Launch” Knotens in den Setup-Baum kann es sein, dass Oomph diesen Typ nicht direkt unter “New Child” bzw. “New Sibling” anbietet, sondern im Untermenü “Additional Tasks” versteckt. Diese zusätzlichen Tasks werden erst beim ersten Auswählen in Eclipse installiert – gegebenenfalls muss Eclipse danach neu gestartet werden.

Nach dem Einhängen muss über die Property View noch “Launch Configuration” mit dem Wert generate-source gesetzt werden.

Diesen neuen Schritt im Setup könnte man testen, indem man das zweite Eclipse (in dem das Setup schon ausgeführt wurde) beendet, das Installationsverzeichnis löscht und wie zuvor beschrieben neu installiert. Es geht aber einfacher: Im ersten laufenden Eclipse wird die Setup-Datei editiert und gespeichert, im zweiten laufenden Eclipse (dem “Ziel”) wählt man “Help → Perform Setup Tasks” und führt so die Tasks des Setups erneut aus. Dadurch kann man neue Schritte deutlich schneller anpassen und testen.

Wird wie im ersten Eclipse ein neuer Task-Typ (hier “Launch”) verwendet, muss Oomph auch im zweiten Eclipse diese Extension nachinstallieren und dazu Eclipse gegebenenfalls neu starten. Dies wird leider nicht wie sonst üblich über einen modalen Dialog angezeigt, sondern nur indirekt im Log des Eclipse-Updaters.

Bequemer

Ein gutes IDE-Setup für einen neuen Entwickler beinhaltet natürlich noch einige zusätzliche Schritte, die aber nach demselben Muster durchgeführt werden können und für die es passende Task-Arten gibt:

Einstellungen von Views wie z.B. dem Package Explorer lassen sich leider ohne internes Wissen nicht so einfach einstellen.

Fazit

Das “Oomph Authoring”3 Wiki, eine Unterseite des “Eclipse Installer” Wiki4, bietet weitere Dokumentation für Oomph.

Oomph hilft Entwicklern beim Aufsetzen einer neuen, funktionierenden IDE – sei es bei internen Projekten oder bei Opensource-Projekten. So verwendet zum Beispiel das Xtext-Projekt ein komplexes und dennoch flexibles Setup um für neue Contributoren die Einstiegshürde möglichst gering zu halten. Warum sollte dies nicht auch bei internen Projekten so sein?

Kurzbiografie

Andreas Heiduk ist als Senior Consultant für MATHEMA Software GmbH tätig. Seine Themenschwerpunkte umfassen die Java Standard Edition (JSE) und die Java Enterprise Edition (JEE). Daneben findet er die unterschiedlichsten Themen von hardwarenaher Programmierung bis hin zu verteilten Anwendungen interessant.