Eclipse-RCP-Anwendungen mit Maven und Tycho bauen

Definition der Target-Plattform

Eine Target-Plattform ist eine Menge von Plug-ins, auf deren Basis die zu entwickelnde Anwendung gebaut und ausgeführt wird. Die zur Entwicklung verwendete Eclipse-Umgebung (IDE) dient standardmäßig als Target-Plattform. Damit kann aber nur schwer sichergestellt werden, dass verschiedene Entwickler die gleichen Plug-in-Versionen verwenden. Änderungen an der IDE durch Updates oder Neuinstallationen könnten Einfluss auf die zu entwickelnde Anwendung haben. Daher ist es ratsam, zwischen IDE und Target-Plattform zu unterscheiden. Eine separate Target-Plattform kann im einfachsten Fall durch Kopieren der IDE oder durch Download und Entpacken des RCP SDK erzeugt werden. Empfehlenswert ist jedoch die Verwendung einer Target-Definition, mit der die Target-Plattform während des Builds erzeugt wird.

Die Target-Definition insurance.target der Beispielanwendung wurde mit dem a href=“http://help.eclipse.org/helios/index.jsp?nav=/4“ target=“blank“>Target-Definition-Editor der PDE [4] erzeugt. Zur Auswahl der notwendigen Plug-ins können u.a. Verzeichnisse, Installationen und Software Site angegeben werden. Für die Beispielanwendung wurden die Software Sites von Eclipse 3.6 und SWTBot angegeben, sodass die notwendigen Plug-ins automatisch durch den Eclipse-Provisierungsmechanismus p2 heruntergeladen werden. Mit der Option Include all environments muss man sich nicht mehr um Deltapacks kümmern, wenn die RCP-Anwendung für verschiedene Plattformen gebaut werden soll. Sofern die Target-Definition unter Versionskontrolle steht, ist sichergestellt, dass alle Entwickler die gleiche Target-Plattform verwenden.

Bei diesem Ansatz wird man leider abhängig von externen p2/update-sites, die eventuell nicht immer erreichbar sind und die notwendigen Plug-ins vielleicht nicht für alle Zeit bereithalten werden. Zwar müssen die Plug-ins und Features nur einmal ins lokale Maven-Repository heruntergeladen werden, aber bei jedem Build werden die p2-Repository-Metadaten heruntergeladen, sodass der Build-Prozess länger dauert als notwendig. Aus diesen Gründen empfiehlt es sich, eine lokale p2/update-site zu verwenden, die die Target-Plattform beinhaltet. Beispielsweise unterstützt Nexus Professional Eclipse-p2-Repositories.

Automatisiertes UI-Testen

Der beschriebene Build-Prozess wird erst durch automatisierte Tests komplett. Zur Qualitätssicherung der Beispielanwendung wollen wir SWTBot-Tests einsetzen. SWTBot wird uns dabei als „Klick-Roboter“ [8] dienen, d.h. die Oberfläche wird durch Aufrufe des SWTBot-API bedient. Wie dieses API eingesetzt werden kann, um robuste Oberflächentests zu entwickeln, wurde bereits im Eclipse Magazin [8], [9] beschrieben. Die Probleme [9], die es mit JUnit4 und Eclipse 3.5 gab, sind mit Eclipse 3.6 behoben worden. Daher werden wir JUnit 4 verwenden und darin das SWTBot-API aufrufen. Die JUnit-Tests erhalten folgende Annotation:

@RunWith(SWTBotJunit4ClassRunner.class)

Wie wir in Listing 3 bereits gezeigt haben, kann die Ausführung der Tests mit geringem Aufwand automatisiert werden. Jetzt wird auch verständlich, warum der Parameter useUIHarness auf true gesetzt wurde, denn während der Tests wird die Anwendung gestartet und die Oberfläche bedient (Abb. 2).

Abb. 2: Die Oberfläche wird automatisch durch die Tests bedient
Weitere Projektabhängigkeiten

Einer der Vorteile von Maven ist die Leichtigkeit, mit der Projektabhängigkeiten hinzugefügt werden können. Maven löst diese Abhängigkeiten selbstständig mit einem passenden Artefakt aus einem entfernten oder lokalen Repository auf. Mit Tycho funktioniert das leider nicht ganz so einfach, denn alle Projektabhängigkeiten können nur mit einem Bundle aus dem aktuellen Projekt oder aus der Target-Plattform aufgelöst werden. Für solche Fälle bietet Tycho den Parameter pomDependencies=consider. Dieses fortgeschrittene Tycho-Feature sollte jedoch laut Dokumentation nur als Notlösung verwendet werden. Bei diesem Feature wird die Diskrepanz zwischen der Auflösung der transitiven Abhängigkeiten von Maven und OSGi deutlich, denn alle transitiven Abhängigkeiten müssten explizit angegeben werden. Auch wenn es gelingt, dieses heikle Feature erfolgreich einzusetzen, müssen die benötigten Bibliotheken in OSGI-Bundles bzw. Plug-ins konvertiert werden. Leider ist es nicht möglich, den „POM-first“- und „Manifest-first“-Ansatz im gleichen Reactor-Build zu verwenden, denn Abhängigkeiten werden sehr früh während des Maven-Build-Prozesses aufgelöst, sodass Manifestdateien von OSGi-Bundles nicht für „POM-first“-Projekte generiert werden können.

An dieser Stelle dürfen wir Orbit [10] und das SpringSource-Bundle-Repository [11] nicht vergessen. Dies sind Repositories, die OSGi-Versionen von Open-Source-Bibliotheken beinhalten, die zur Target-Plattform hinzugefügt werden können.

Fazit

Mit Tycho macht Sonatype einen großen Schritt vorwärts im Bestreben, Eclipse und Maven zu einem schlüssigen Gesamtkonzept zu verbinden. Mit dem „Manifest-first“-Ansatz von Tycho sind die zahlreichen PDE/JDT-Features, wie beispielsweise die editorgestützte Erstellung der Target-Definition-Dateien, trotz Maven nutzbar. Die Eclipse-Plug-in-Entwicklung mithilfe der PDE wird nicht eingeschränkt, denn Tycho unterstützt alle PDE-Projekttypen. Die Eclipse-RCP-Entwicklung wird also nicht schlechter, aber wird sie besser? Ja, denn mit Maven kann Headless gebaut und getestet werden. Und läuft der Maven-Build-Prozess erst einmal, dann fällt der Einsatz eines Continuous-Integration-Servers auch nicht mehr schwer. Der vorgestellte Build-Prozess erfüllt damit die am Anfang des Artikels formulierten Anforderungen. Schwierig ist jedoch die Integration zusätzlicher Abhängigkeiten, denn diese müssen erst in ein OSGi-Bundle verwandelt werden und können auch dann nicht ohne Weiteres zur Target-Plattform hinzugefügt werden. Daher bleibt zu hoffen, dass Tycho auch für solche wiederkehrenden Probleme praktikable Lösungen bereitstellen wird.

Kai Spichale arbeitet als Senior Software Engineer beim IT-Dienstleistungs- und Beratungsunternehmen adesso AG und entwirft und entwickelt Unternehmensanwendungen mit allem, was die Java-Plattform zu bieten hat.
Kommentare

Schreibe einen Kommentar

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