Automatisiertes Aufsetzen von Entwicklungsumgebungen

Eclipse Oomph bringt Schwung ins Projekt

Eike Stepper

©Shutterstock/empics

Wer hat nicht schon einmal geflucht, wenn die ersten Tage in einem neuen Softwareprojekt für das Aufsetzen von IDE und Workspace flöten gehen? Die Installationsanleitung ist so lang wie die Bibel – und genauso alt. Dutzende Plug-ins müssen installiert werden, diverse Repositories geklont und importiert. Wie bitte, Gerrit, Hudson und Bugzilla sind einzurichten? Warum ist der Workspace voller Fehler? Und was ist eine Target Platform? Kurz: Warum beginnt der agile Prozess eigentlich erst nach dieser nervenaufreibenden und kostspieligen Tortur?

Der Agile weiß: Funktionierende Software ist wichtiger als umfassende Dokumentation. Dieses gleichermaßen einfache wie effektive Prinzip auf die Phase der Werkzeugeinrichtung zu Projektbeginn auszudehnen ist das Ziel des neuen Eclipse-Projekts Oomph [1], [2]. Dazu wird eine ganze Reihe nützlicher Eclipse-Plug-ins angeboten, die separat oder kombiniert genutzt werden können, um den Entwicklungsalltag effizienter zu gestalten. Profilbasierte Verwaltung projektspezifischer Einstellungen, Versionsverwaltung für Plug-ins und Features, dynamische Working Sets und Ersatz für den holprigen Target Platform Editor sind nur einige Beispiele; aber der Clou ist die vollständige Automatisierung der Einrichtung all dieser und beliebiger weiterer Technologien durch eine modellbasierte Set-up-Engine.

Dieser Artikel betrachtet Oomph aus der Perspektive desjenigen, der einfach eine standardisierte Entwicklungsumgebung für ein vorhandenes Projekt aufsetzen möchte. Das Erstellen von Set-up-Modellen für eigene Projekte wird in einer späteren Ausgabe behandelt.

Ihre Auswahl, bitte!

Die Benutzeroberfläche von Oomph besteht hauptsächlich aus einem Eclipse-Wizard, der den Benutzer durch alle Aspekte des Provisionierungsprozesses geleitet. Für das Aufsetzen vollkommen neuer Entwicklungsumgebungen bietet Oomph einen ausführbaren Installer an, der wie jedes andere Eclipse Package heruntergeladen und entpackt wird. Nach dem Starten des Installers wird die erste Wizard-Seite angezeigt (Abb. 1), die die Auswahl des zu installierenden Basisprodukts aus einem oder mehreren Produktkatalogen erlaubt.

Abb. 1: Die Produktauswahl im Oomph Installer

Der Eclipse-Katalog wird direkt aus den p2-Repositories des Eclipse-Packaging-Projekts generiert und ermöglicht somit dem Benutzer, jede beliebige Version jedes Produkts zu installieren, das er normalerweise auf der Eclipse-Downloadseite finden würde.

Darf’s ein wenig schneller sein?

Oomph unterstützt den Einsatz globaler Bundle Pools für alle Aspekte der Installation und optional sogar der Target Platform. Das heißt, wenn mehrere Produkte installiert oder mehrere Target-Plattformen aufgesetzt werden, können alle Installationen und Target-Plattformen die gemeinsamen Bundles teilen und müssen jedes einzelne Bundle nur einmal herunterladen. Das reduziert den benötigten Plattenplatz und die Installationsdauer dramatisch. Natürlich kann das Bundle Pooling auch ausgeschaltet werden, wenn man eine mit den entpackten Eclipse Package Downloads identische Installation erhalten möchte.

Mittels Manage Bundle Pools öffnet man einen Dialog (Abb. 2), der das Erstellen, Analysieren und Aufräumen globaler Bundle Pools genauso unterstützt wie das automatische Reparieren defekter Artefakte durch erneuten Download derselben Version aus dem Internet. Damit gehören Sorgen über den Ausfall gleich einer ganzen Reihe von Installationen und Target-Plattformen aufgrund beschädigter Downloads der Vergangenheit an.

Abb. 2: Bundle Pools ermöglichen kleine, schnelle und sichere Installationen

 Darf’s ein Projekt mehr sein?

Wer bereits den frühen Prototyp von Oomph kannte, dem fällt auf, dass die neue Architektur [4] wesentlich flexibler und weniger invasiv ist. Denn auf der zweiten Wizard-Seite (Abb. 3) sieht man, dass nicht mehr genau ein Projekt für das Provisionieren des Workspace ausgewählt werden muss, sondern dass das auch für kein Projekt oder für mehrere Projekte gleichzeitig möglich ist.

Abb. 3: Die Projektauswahl im Oomph Installer

Dazu doppelklickt man der Reihe nach im oberen Dialogbereich auf die Projekte, deren Sourcecode man im Workspace haben möchte. Die so zusammengestellten Projekte werden im unteren Dialogbereich aufgelistet, sodass man pro Projekt den gewünschten Stream auswählen kann. Ein Stream ist Oomphs logisches Äquivalent zu einem Branch in Git, SVN oder CVS.

Workspace-Komposition ist ein einzigartiges Merkmal von Oomph und definitiv eine technische Herausforderung, die vor allem durch Oomphs flexible, sichere und hochperformante Target-Platform-Implementierung ermöglicht wird.

Eine Frage der Einstellung

Die auf den ersten beiden Wizard-Seiten ausgewählten Produkte und Projekte beziehen sich auf Set-up-Modelle, die an bestimmten Stellen Platzhalter für benutzerspezifische Werte aufweisen. Mithilfe dieser Variablen wird die Installation nun (Abb. 4) an lokale Gegebenheiten und eigene Vorlieben angepasst, zum Beispiel die Pfade für Installation, Workspace und weitere Einrichtungen, die Log-ins für Remote-Dienste, die Art des Zugriffs auf Git und so weiter. Abb. 4: Die Anpassung der Installation an Benutzerbedürfnisse

Bei der allerersten Installation mit Oomph sind offensichtlich je nach Produkt- und Projektauswahl eine ganze Menge Eingaben zu tätigen, aber die meisten dieser Einstellungen werden aufgezeichnet, und das teilweise projektübergreifend. So wird bei der wiederholten Verwendung von Oomph der Eingabeaufwand erheblich reduziert; beispielsweise wird das Eclipse-Log-in nicht mehr abgefragt, wenn zuvor bereits einmal ein Eclipse-Projekt aufgesetzt wurde. Bei der Reinstallation einer früheren Produkt- und Projektmenge wird in aller Regel nur noch der einfache Installationspfad anzugeben sein.

Bestätigung tut gut

Auf der nun folgenden Bestätigungsseite (Abb. 5) werden die Set-up-Tasks aufgelistet, die von der Set-up-Engine zu diesem Zeitpunkt (dem so genannten Bootstrap-Trigger) für nötig befunden werden. Einzelne Tasks können normalerweise manuell deaktiviert werden, aber während dieser initialen Installation sind die meisten absolut erforderlich.

Abb. 5: Die Bestätigungsseite ermöglicht eine abschließende BegutachtungMit der Offline-Checkbox kann eine dem Maven-Offline-Modus vergleichbare, Oomph-eigene p2-Optimierung eingeschaltet werden, um langwierige Remote-Queries deutlich zu reduzieren (Metadata Caching). Die Betätigung des Next-Buttons startet schließlich den eigentlichen Installationsvorgang.

Machen Sie es so!

Die fünfte und letzte Wizard-Seite (Abb. 6) zeigt nun den tatsächlichen Fortschritt der Installation an. Im oberen Teil des Dialogs wird dabei der gerade ausgeführte Set-up-Task hervorgehoben und im unteren Teil werden die von diesem Task erzeugten Log-Meldungen angezeigt.

Abb. 6: Die Fortschrittsanzeige macht die Installation nachvollziehbarBei der ersten Installation eines Produkts kann der Prozess recht lange dauern, da eine große Anzahl Bundles aus dem Internet heruntergeladen wird, aber nachfolgende Installationen profitieren enorm von der Verwendung globaler Bundle Pools und dauern teilweise weniger als 20 Sekunden. Sobald der Installationsprozess abgeschlossen ist, wird das installierte Produkt automatisch gestartet, und alle verbleibenden Set-up-Tasks werden im laufenden Produkt ausgeführt (durch den Start-up-Trigger), wobei wiederum die Fortschrittsseite des Set-up-Wizards angezeigt wird (Abb. 7).

Abb. 7: Die Vervollständigung der Installation im installierten Produkt

Für diesen Artikel wurde das Oomph-Projekt selbst für das Provisionieren des Workspace ausgewählt. Daher beinhalten die Tasks das Klonen des Git-Repositories, das Betanken der für die Oomph-Sourcen benötigten Target Platform sowie die Einrichtung dynamischer Working Sets, um die Sourcen logisch zu organisieren. Wenn der Vorgang abgeschlossen ist, sieht der Workspace aus wie in Abbildung 8.

Abb. 8: Die standardisierte Umgebung für Oomph-Entwickler

Beachtenswert ist unter anderem, dass die für die Bearbeitung bestimmter Oomph-Artefakte benötigten Werkzeuge wie der EMF-Codegenerator oder der EcoreTools-Diagrammeditor bereits zusammen mit dem Produkt installiert wurden. Der Benutzer kann nun mit den Oomph-Sourcen in derselben Weise arbeiten wie auch die Oomph-Committer. Er kann Bug Reports mittels der automatisch eingerichteten Mylyn Queries erstellen, den Status der konfigurierten Hudson-Jobs überwachen und natürlich seine Änderungen an den Sourcen einfach via Gerrit committen.

Dein Eclipse oder mein Eclipse?

Ein weiterer spannender Aspekt von Oomph ist die Fähigkeit, persönliche Präferenzen zu verwalten. Über die Main-Toolbar von Eclipse wird der Editor für User-Tasks (Abb. 9) geöffnet und über die Editor-Toolbar dann der normale Eclipse-Preferences-Dialog.

Abb. 9: User-Tasks automatisieren die Anpassung an Benutzerbedürfnisse

Alle Änderungen der Einstellungen in diesem Dialog werden als Set-up-Tasks aufgezeichnet und automatisch oder nach definierbaren Kriterien auf bestimmte Installationen sowie Updates von Installationen angewendet. Die Klagen über standardmäßig nicht eingeschaltete Zeilennummern in Texteditoren (sowie alle anderen Funktionen, deren Voreinstellungen eben niemand gleichermaßen gut für alle denkbaren Benutzer definieren kann) gehören somit der Vergangenheit an. Außerdem kann jede beliebige Task-Art manuell den User-Tasks hinzugefügt werden, zum Beispiel zusätzliche p2-Tasks, um die Lieblings-Plug-ins des Benutzers unabhängig von den gewählten Produkten und Projekten in jeder Umgebung bereitzustellen.

Fazit

Oomph wurde ursprünglich entwickelt, um das Beitragen zu Open-Source-Projekten für Einsteiger so leicht wie möglich zu machen und damit auch mehr neue Entwickler anzuziehen. Es ist aber offensichtlich, dass die Oomph-Methode im Umfeld kommerzieller Softwareentwicklung dieselben positiven Effekte entfalten und zu nennenswerten Kosteneinsparungen führen kann. Generell gilt: Nutze Zeit zum Entwickeln, nicht zum Vorbereiten; investiere in Automation, nicht in Dokumentation. Die dafür nötige Technologie ist heute verfügbar.

Aufmacherbild:  Impulse and Momentum von Shutterstock / Urheberrecht: empics

Verwandte Themen:

Geschrieben von
Eike Stepper
Eike Stepper
Eike Stepper ist seit 1991 unabhängiger Berater und war von Beginn an enthusiastisch in Eclipse involviert. Er ist Leiter der Eclipse-Projekte CDO, Net4j und Oomph sowie Committer in diversen anderen Projekten. Eike gewann 2010 den Eclipse Top Committer Award und ist berufenes Mitglied des Eclipse Architecture Councils.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: