Fix und Fertig – Eclipse automatisiert aufsetzen
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).
Der Baum ist mit folgenden Knoten vorbelegt:
- “JRE Task” legt das verwendete JRE fest.
- “Eclipse Ini” definiert die IDE-Startparameter – also z.B. den maximalen Speicherverbrauch.
- “Resource Creation” konfiguriert die “Package Explorer” View um. Diese Einstellungen sind leider nicht über die normalen Benutzereinstellungen konfigurierbar.
- “Variable Task” definiert eine eigene Oomph-Variable. Dieses Beispiel benötigt sie nicht.
- “P2 Director” ist für die Installation zusätzlicher Plugins oder Features zuständig.
- “Git Clone” klont ein Git Repository.
- “Modular Target” ist für den Projekt-Import bei der Entwicklung von Eclipse-Plugins nötig. In diesem Beispiel wird dieser Knoten durch einen anderen Typ ersetzt.
- “Working Set Task” gruppiert die importierten Projekte nach beliebigen Kriterien.
- “Master Stream” legt den Git-Branch fest.
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:
-
“Modular Target” ist für die Entwicklung von Eclipse-Plugins oder Features geeignet – der Task importiert alle Plugin-Projekte, die für ein angegebenes Feature nötig sind.
-
“Maven Import” importiert Maven Projekte.
-
“Projects Import” importiert Eclipse-Projekte.
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 “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/
.
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:
-
Projektspezifische Plugins installieren: Diese hängt man als Kinder des “P2 Director” Knoten ein. URLs für zusätzliche Update-Site kann man ebenfalls hier ablegen.
-
Preferences einstellen: Insbesondere die Optionen für “Organize Imports” und die Code-Formatter Einstellungen können automatisch festgelegt werden.
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?