Export und Verteilung von RCP-Anwendungen

Export und Verteilung von RCP-Anwendungen

Target Platform

Wie wir gesehen haben, besteht eine RCP Anwendung aus einer Menge Plug-ins, die die Eclipse Plattform erweitern. Ohne die Plug-ins der Plattform könnten sie nicht funktionieren. Woher kommen diese Plattform-Plug-ins?

Werfen wir einen Blick in eine Startkonfiguration: Eigene Plug-ins stehen unter Workspace. Die Plug-ins der Eclipse Plattform werden unter Target Platform aufgelistet:

Die Target Platform definiert die Menge von Plug-ins, auf der eine RCP Anwendung entwickelt und ausgeführt wird. Eine Target Plattform besteht aus einem Ordner mit Plug-ins. Alle Plug-ins in diesem Ordner können bei der Anwendungsentwicklung verwendet werden. Die Target Plattform wird in den Eclipse-Einstellungen unter Plug-in Development festgelegt:

Standardmäßig wird die Eclipse IDE selbst als Target Plattform verwendet. Diese enthält jedoch viel mehr Plug-ins als für eine RCP-Anwendung notwendig und sinnvoll sind. Es ist daher sehr empfehlenswert, die Zielplattform von der IDE zu entkoppeln, also eine reduzierte Target Plattform für die RCP-Anwendung zu verwenden, die nur die benötigten Plug-ins enthält:

Alle Entwickler verwenden so dieselbe, exakt definierte Zielplattform.
Die Version der Plug-ins ist unabhängig von der IDE-Version und Entwickler können neuere Versionen der Eclipse IDE verwenden, auch wenn die Anwendung selbst noch nicht aktualisiert werden soll.
Es können keine unerwünschten Abhängigkeiten zu IDE-Plug-ins eingeführt werden.
Häufig benötigen RCP-Anwendung zusätzliche Plug-ins, die nicht in der IDE installiert werden sollen - beispielsweise BIRT (Reporting Framework) oder Plug-ins für andere Betriebssysteme (Eclipse Delta Pack).

Eine minimale Target Plattform für die RCP-Entwicklung finden Sie unter der Bezeichnung “RCP SDK” auf der Eclipse-Downloadseite.

Eclipse RCP-Anwendungen exportieren: Produkte

Der Export einer selbstständigen (d.h. ohne IDE lauffähigen) Version einer RCP-Anwendung erfolgt auf der Grundlage eines sog. Products. Ein Produkt definiert vor allem, aus welchen Plug-ins die Anwendung besteht. Zudem haben Sie über das Produkt die Möglichkeit, Ihre Anwendung zu “branden”, d.h. mit optischen Details wie Titel, Splash-Screen und Icons zu versehen.

Ein Produkt besteht aus einer Extension zu org.eclipse.core.runtime.products und einer .product-Datei. Der Extension Point ist nur zur Laufzeit relevant und enthält vor allem die Informationen zum Branding der Anwendung. Die .product-Datei hingegen ist nur zur Buildzeit relevant. Sie steuert den PDE Build, den Eclipse-eigenen Buildprozess, der die Plug-ins der Anwendung compiliert, zu JAR-Dateien verpackt und eine lauffähige Gesamtanwendung zusammenstellt.

Das Produkt können Sie in einem zentralen Plug-in Ihrer Anwendung definieren, beispielsweise das Plug-in, welches auch die RCP-Anwendungsklasse beherbergt. Wenn Sie mehrere Produkte verwalten, beispielsweise für verschiedene Varianten Ihrer Anwendung, legen Sie die Produkte am besten in separaten Plug-ins an.

Ein neues Produkt erzeugen Sie mit File > New > Other > Plug-in Development > Product Configuration. Dieses können Sie aus einer vorhandenen Startkonfiguration erzeugen oder leer generieren:

Damit erzeugen Sie zunächst die .product-Datei. In dieser können Sie nun Ihr Produkt konfigurieren. Am wichtigsten ist dabei die Festlegung, aus welchen Plug-ins das Produkt besteht. Sie können unter Configuration Ihre Anwendungs-Plug-ins hinzufügen und mit Add Required alle abhängigen Plug-ins ergänzen lassen. Unter Splash und Branding können Sie das Aussehen der Anwendung konfigurieren.

Die Extension zu org.eclipse.core.runtime.products können Sie ebenfalls aus dem Produkt heraus anlegen. Sie vergeben dafür eine eindeutige Produkt-ID, mit der das Produkt zur Laufzeit identifiziert wird. Dadurch wird eine entsprechende Extension angelegt und alle zur Laufzeit relevanten Informationen, vor allem zum Branding der Anwendung, übertragen.

Ändern Sie zu einem späteren Zeitpunkt das Branding der Anwendung, können Sie die Extension mit einem Klick auf Synchronize aktualisieren:

Haben Sie das Produkt erstellt, empfiehlt es sich, es zunächst aus der IDE heraus zu starten. Dazu konfigurieren Sie Ihre Startkonfiguration so, dass das Produkt selbst gestartet wird:

Wichtig ist dabei zu beachten, dass die Auswahl des Produktes keinen Einfluss auf die Menge der gestarteten Plug-ins nimmt! Um die Korrektheit der Plug-in-Konfiguration des Produktes in der IDE zu testen, können Sie ihre Startkonfiguration löschen und über das Produkt neu erstellen. Dies erzeugt eine Startkonfiguration gemäß den Angaben im Produkt:

Haben Sie das Produkt erstellt und in der IDE getestet, können Sie es mit File > Export > Eclipse Product exportieren:

Build-Konfiguration für Plug-ins: build.properties

Ihre Plug-ins werden beim Export durch den PDE-Buildprozess gebaut und zu einer selbstständig lauffähigen Anwendung verpackt. Dabei gilt es Folgendes zu beachten: Beim Export werden nur die Klassen und Ressourcen-Dateien aus den Quellpfaden wie src/ exportiert. Zusätzliche Ressourcen-Dateien, die zur Laufzeit zur Verfügung stehen sollen, müssen in der build.properties-Datei des Plug-ins konfiguriert werden:

source.. = src/
output.. = bin/
bin.includes = plugin.xml,\
               META-INF/,\
               .,\
               icons/

Dies betrifft vor allem die plugin.xml Datei sowie den icons-Ordner: Wurden diese erst nach der Erstellung des Plug-ins hinzugefügt, müssen sie unter Umständen manuell zur build.properties hinzugefügt werden. Häufig fällt das Fehlen dieser Konfiguration erst beim ersten Export auf, da beim Start von Plug-ins aus der IDE heraus alle Dateien im Plug-in-Ordner zur Verfügung stehen.

Plug-ins gruppieren: Features

Bei größeren Anwendungen wird die Menge der Plug-ins schnell unübersichtlich. Abhilfe schaffen hier sog. Features. Ein Feature besteht neben einigen Angaben wie Name, Versionsnummer aus einer Auflistung von Plug-ins:

<?xml version="1.0" encoding="UTF-8"?>
<feature
      id="com.example.somefeature"
      label="Some Feature"
      version="1.0.0">

   <plugin id="com.example.someplugin"/>
   <plugin id="com.example.someotherplugin"/>

</feature>

Ein eigenes Feature können Sie mit File > New > Other > Plug-in Development > Feature Project anlegen. Häufig werden alle Anwendungs-Plug-ins in einem Feature abgelegt, bei größeren Projekten macht auch die Unterteilung in überschaubare Unter-Features Sinn.

Das standardmäßig vorhandene Feature org.eclipse.rcp stellt Ihnen alle Plug-ins der RCP-Plattform bereit.

In einer Produktkonfiguration können Sie konfigurieren, dass das Produkt Feature-basiert sein soll. Sie stellen dann lediglich Features statt Plug-ins zusammen, wodurch die Produktkonfiguration deutlich übersichtlicher wird:

RCP-Anwendungen können auf zahlreichen Wegen zum Anwender gelangen. Im Folgenden möchte ich einen Überblick über die Möglichkeiten geben:

Export + Traditionelles Datei-Deployment

Die einfachste Variante, eine RCP-Anwendung auszuliefern, ist sie zu exportieren und die Anwender mit dem Endprodukt zu versorgen. Dieser Vorgang kann problemlos über traditionelle Softwareverteilungswerkzeuge erledigt werden, die in vielen Unternehmen bereits vorhanden sind. Dieses Vorgehen ist für viele Anwendungsszenarien die einfachste und empfehlenswerteste Variante.

Der Build der Anwendung kann mittels des PDE Headless Builds oder mittels Buckminster automatisiert werden, so dass nicht jedes mal die IDE bemüht werden muss, um das Produkt zu exportieren. Außerdem kann die Anwendung unabhängig vom Betriebssystem exportiert werden. Wenn Sie das Eclipse Delta Pack (zu finden auf der Eclipse-Downloadseite) in die IDE oder die Buildumgebung installieren, können Sie Anwendungen für jede beliebige Zielplattform erzeugen:

Multi-platform export

Weitere Informationen:

Java Web Start

Alternativ können Eclipse RCP Anwendungen per Web Start ausgeliefert werden. Dabei gilt es einiges zu beachten, da die JARs für Web Start-Anwendungen signiert sein müssen und Einschränkungen bei der Ausführung eines OSGi-Containers in einer Web-Start-Umgebung beachtet werden müssen.

Weitere Informationen:

p2

In Eclipse 3.4 wurde der Eclipse-eigene Update Manager durch Equinox p2 abgelöst. p2 stellt eine allgemeine Plattform für die Softwareverteilung bereit, kann also über Eclipse-Anwendungen hinaus verwendet werden, um Softwareinstallationen und Softwarearchive zu verwalten. p2 lässt sich am ehesten mit Paketverwaltungssoftware wie apt, rpm oder gem vergleichen. Grundlegend bei p2 ist die Verwendung von Metadata Repositories, die Software und beschreibende Metadaten in Form sog. Installable Units (IUs) enthalten. Eine IU repräsentiert in der Regel ein Produkt, ein Feature oder Bundle. Beim PDE-Build bzw. Export können über die Option Generate metadata repository entsprechende Repositories erzeugt werden.

p2-Repositories können auf verschiedene Arten zur Installation von Software verwendet werden:

Über die aus Eclipse bekannte Oberfläche, die mit dem Feature org.eclipse.equinox.p2.user.ui auch in RCP-Anwendungen eingebettet werden kann.
Über vorläufige API in den p2 Bundles (org.eclipse.equinox.p2....)
Mit dem Kommandozeilentool p2 director application

Weitere Informationen: