Eclipse-Plattform
installieren und aktualisieren

Letzte Überarbeitung: 14.06.2001, 10.45 Uhr - Version: 0.12

 
Hinweis: Die Entwicklung des Aktualisierungsmanagers ist noch nicht abgeschlossen. Vor dem Erreichen der Stabilität kann es daher zu Änderungen kommen. Der Aktualisierungsmanager wird im vorliegenden Status zur Verfügung gestellt, um Rückmeldungen der ersten Anwender zu erhalten, und unter der Voraussetzung, dass Details der Installationsstruktur auf erhebliche Weise geändert werden könnten.

Einführung
Szenarien
Konventionen für die Paketerstellung
       Konzepte
       Komponentenarchiv
       Konfigurationsarchiv
       Paketinformationen übersetzen
       Überlegungen zur Sicherheit
       Pakete für Landessprachen erstellen
       Pakete für zielspezifische Unterstützung erstellen
       Pakete für Unterstützungselemente erstellen
Installationsstruktur
       Unterschiede zwischen Komplett- und Referenzinstallation
       Dateisystemzuordnung: Komplettinstallation
       Arbeitsbereichdateien
       Dateisystemzuordnung: Referenzinstallation
Eclipse starten
Überlegungen zur Aktualisierung
       Nicht zur Plattform gehörende Komponenten aktualisieren
       Plattform aktualisieren
       JRE aktualisieren
       Produktdateien aktualisieren
       Startunterstützung aktualisieren
       Aktualisierungsfehler beheben
       Falsche Aktualisierungen korrigieren
       Installation bereinigen
       Nicht verwaltete Eclipse-Funktion
Überlegungen zur Installation
       Neue Installation
       Gemischte Installation
       Plattformspezifische Registrierung
Überlegungen zur Entwicklung
       Unabhängigkeit von Installationsposition
       Native ausführbare Ressourcen
       Unterstützung von parallelen Plug-in-Versionen
       Versionsmigration

Einführung

Das vorliegende Dokument stellt die Unterstützung vor, mit der die Bereitstellung von Funktionen in der Eclipse-Plattform verwaltet werden kann.

Szenarien

Die Eclipse-Plattform enthält einen integrierten Aktualisierungsmanager, der im Rahmen der Installation von auf Eclipse basierenden Funktionen sowie zur Bereitstellung von Funktionsaktualisierungen und Funktions-Upgrades verwendet wird. Die erste Version von Eclipse unterstützt die folgenden Szenarien:

Konventionen für die Paketerstellung

Konzepte

Plug-in
Eclipse-Entwickler erstellen Plug-ins. Plug-ins sind die Grundeinheiten für die Ausführung, die durch die Eclipse-Laufzeitumgebung erkannt werden. Im Allgemeinen sind Plug-ins für Benutzer, die bei einer Installation und Aktualisierung Funktionen auswählen, nicht erkennbar. Dies liegt daran, dass die Grenzen der Plug-ins von den Entwicklern aus entwicklungsbedingten Gründen (z. B. erneute Verwendung einer Funktion) festgelegt werden und dem Benutzer einen falschen Eindruck hinsichtlich der Unterteilung von Funktionseinheiten vermitteln.

So lange die Entwicklung von Plug-ins nicht abgeschlossen ist (sie also häufig geändert werden), ist ihre interne Dateistruktur so aufgebaut, wie es für den Entwickler am praktikabelsten ist. Dies ist generell von dem spezifischen verwendeten Entwicklungstool abhängig. Normalerweise richtet ein Entwickler ein Plug-in jedoch wahrscheinlich so ein, dass es nicht aus einer Datei .jar, sondern aus einer Verzeichnisbaumstruktur heraus ausgeführt wird, die erkennbare Dateien .class enthält. (Die Erstellung einer Datei .jar bedeutet einen zusätzlichen Arbeitsschritt, der im Rahmen einer Entwicklung nicht erwünscht ist.) Daher achtet ein Entwickler in dieser Phase nicht verstärkt darauf, Informationen zur Versionierung zu integrieren, da sich das Plug-in kontinuierlich ändert.

Wenn die Entwicklung des Plug-ins jedoch so weit fortgeschritten ist, dass es als Paket erstellt werden kann, muss es in eine für die Paketerstellung und Installation geeignete Form konvertiert werden. In der Regel bedeutet dies, dass die JAR-Datei(en) für die Laufzeit erstellt und alle im Rahmen der Entwicklung verwendeten Dateien (Quelle, erkennbare Dateien .class usw.) entfernt werden. Außerdem wird das Manifest plugin.xml mit der formalen Plug-in-Version aktualisiert, und die Version wird im Namen des Plug-in-Verzeichnisses angegeben (Details finden Sie unter "Unterstützung von parallelen Plug-in-Versionen").

Plug-in-Fragment
Mit Hilfe von Plug-in-Fragmenten (kurz "Fragmente" genannt) können Pakete unabhängig von bestimmten Aspekten des Basis-Plug-ins erstellt werden. Hierzu gehören unter anderem übersetzte Ressourcen für das Plug-in, betriebssystemspezifischer Code bzw. spezifischer Code für Systeme mit Fenstertechnik oder zielgruppenspezifischer Plug-in-Inhalt für alternative Benutzer (z. B. Informationen für SDK-Entwickler, die zusammen mit einem Plug-in zur Verfügung gestellt werden). In der Laufzeit werden Fragmente logisch in das Basis-Plug-in gemischt. Hinsichtlich der Paketerstellung können sie entweder physisch in das Paket des Basis-Plug-ins aufgenommen oder aber separat gepackt und aktualisiert werden. So kann beispielsweise ein Paket für eine bestimmte Sprache oder für ein bestimmtes Betriebssystem erstellt werden, das von der Verteilung der Basisfunktion unabhängig ist.

Komponente
Eine Komponente ist normalerweise eine Gruppe aus Plug-ins und/oder Plug-in-Fragmenten, die bestimmte Benutzerfunktionen bereitstellen. Komponenten können für die Benutzer im Rahmen des Paketerstellungs- und Installationsprozesses erkennbar sein, da sie jeweils eine Einheit zur Funktionsauswahl darstellen. Komponenten sind außerdem eine Installationseinheit (alle enthaltenen Dateien werden zusammen in 1 Installationsstruktur installiert). Komponenten enthalten eine Versionskennung.

Komponenten werden als Java-Dateien .jar gepackt. Diese Dateien enthalten die erforderlichen Plug-ins, Plug-in-Fragmente sowie ein Manifest für die Komponenteninstallation (eine Datei .xml). Die JAR-Dateien für Komponenten können auf einen Aktualisierungsserver gestellt und dann durch den Eclipse-Aktualisierungsmanager heruntergeladen und aktualisiert werden. Sie können aber auch als Eingabe in einem formalen Paketerstellungsprozess verwendet werden, der mit einer der "herkömmlichen" Installationsprogrammtechnologien ausgeführt wird. Das Format der JAR-Datei für Komponenten und ihr Installationsmanifest werden an späterer Stelle erläutert.

Konfiguration
Eine Konfiguration ist ein versionsgesteuerter Gruppierungsmechanismus für eine Gruppe von versionierten Komponenten. Mit ihr kann beispielsweise angegeben werden, welche Konfiguration aus Komponenten erstellt und zusammen als bestimmte Version eines Produkts getestet wurde.

Konfigurationen werden als Java-Dateien .jar gepackt. Diese Dateien enthalten das Manifest für die Konfigurationsinstallation (eine Datei .xml). Das Manifest enthält Verweise auf die Komponenten, aus denen die Konfiguration besteht, sowie Vorgaben für Installation und Versionsaktualisierung. Es ist zu beachten, dass die JAR-Datei einer Konfiguration nicht die tatsächlichen Komponentendateien, sondern lediglich Verweise enthält.

Die JAR-Dateien für Konfigurationen können auf einen Aktualisierungsserver gestellt und dann durch den Eclipse-Aktualisierungsmanager heruntergeladen und aktualisiert werden. Sie können aber auch als Eingabe in einem formalen Paketerstellungsprozess verwendet werden, der mit einer der "herkömmlichen" Installationsprogrammtechnologien ausgeführt wird. Das Format der JAR-Datei für Konfigurationen und ihr Installationsmanifest werden an späterer Stelle erläutert.

Die aktuelle Eclipse-Implementierung lässt das Verschachteln von Konfigurationen nicht zu.

Komponentenarchiv (.jar)

Gemäß der Konvention werden Komponenten anhand einer strukturierten Kennung identifiziert, die auf dem Internet-Domänennamen des Providers basiert. Das Unternehmen mit der Domäne "eclipse.org" würde beispielsweise die Komponentenkennung "org.eclipse.platform" erzeugen. Die Komponentenkennung wird als Teil des Namens für die JAR-Datei der Komponente verwendet, sowie als Name für das Komponentenverzeichnis innerhalb der JAR-Struktur (und infolgedessen für die Installationsbaumstruktur). Da gleichzeitig mehrere Versionen einer Komponente installiert sein können, wird die Versionskennung durch den Namen der JAR-Datei für die Komponente sowie durch ihren Verzeichnisnamen codiert. Die Versionskennung befolgt das Format, das durch Eclipse für Versionskennungen definiert ist (weitere Informationen finden Sie im Javadoc der Klasse "PluginVersionIdentifier"). Es handelt sich um eine dreiteilige numerische Kennung, die aus einer Hauptkomponenten, einer untergeordneten Komponenten und einer Aktualisierungskomponenten besteht (z. B. 2.4.11).

Der Name hat das Format
<komponenten-id>_<version>

Beispiele:
org.eclipse.platform_1.0.3.jar
com.ibm.tools.jspeditor_3.1.0\install.xml

Die JAR-Datei für eine Komponente hat die folgende interne Pfadstruktur:

install/
    components/
        <komponenten-id>_<version>/
            install.xml
            (Andere optionale Dateien - siehe "Paketinformationen übersetzen")
    plugins/
        <plug-in-id>_<plug-in-version>/
            plugin.xml
            (Andere Plug-in-Dateien)
    fragments/
        <fragment-id>_<fragment-version>/
            fragment.xml
            (Andere Fragmentdateien, kann auch plugin.xml umfassen)

Die JAR-Datei enthält genau einen Pfad "install/components/" mit genau einer Datei install.xml. Sie enthält keines oder mehr Plug-ins in deren relativen Verzeichnissen (mit Qualifikationsmerkmal für die Version). Sie enthält keines oder mehr Plug-in-Fragmente in deren relativen Verzeichnissen (mit Qualifikationsmerkmal für die Version). Außerdem enthält sie das Verzeichnis "meta-inf/", das durch die Java-Dienstprogramme für JAR-Dateien erzeugt wird.

Das Format der Datei install.xml für Komponenten wird durch die folgende DTD-Datei definiert:

<?xml encoding="US-ASCII"?>

<!ELEMENT component (description?, url?, plugin*, fragment*)>
<!ATTLIST component
    label CDATA #IMPLIED
    id CDATA #REQUIRED
    version CDATA #REQUIRED
    provider-name CDATA #IMPLIED
>

<!ELEMENT description (#PCDATA)>

<!ELEMENT url (update*, discovery*)>

<!ELEMENT update EMPTY>
<!ATTLIST update
    url CDATA #REQUIRED
    label CDATA #IMPLIED
>

<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
    url CDATA #REQUIRED
    label CDATA #IMPLIED
>

<!ELEMENT plugin EMPTY>
<!ATTLIST plugin
    label CDATA #IMPLIED
    id CDATA #REQUIRED
    version CDATA #REQUIRED
>

<!ELEMENT fragment EMPTY>
<!ATTLIST fragment
    label CDATA #IMPLIED
    id CDATA #REQUIRED
    version CDATA #REQUIRED
>

Die Elemente und Attribute werden wie folgt definiert:

Konfigurationsarchiv (.jar)

Gemäß der Konvention werden Konfigurationen anhand einer strukturierten Kennung identifiziert, die auf dem Internet-Domänennamen des Providers basiert. Das Unternehmen mit der Domäne "eclipse.org" würde beispielsweise die Konfigurationskennung "org.eclipse.sdk" erzeugen. Die Konfigurationskennung wird als Teil des Namens für die JAR-Datei der Konfiguration verwendet, sowie als Name für das Konfigurationsverzeichnis innerhalb der JAR-Struktur (und infolgedessen für die Installationsbaumstruktur). Da gleichzeitig mehrere Versionen einer Konfiguration installiert sein können, wird die Versionskennung durch den Namen der JAR-Datei für die Konfiguration sowie durch ihren Verzeichnisnamen codiert. Die Versionskennung befolgt das Format, das durch Eclipse für Versionskennungen definiert ist (weitere Informationen finden Sie im Javadoc der Klasse "PluginVersionIdentifier"). Es handelt sich um eine dreiteilige numerische Kennung, die aus einer Hauptkomponenten, einer untergeordneten Komponenten und einer Aktualisierungskomponenten besteht (z. B. 2.4.11).

Der Name hat das Format
<konfigurations-id>_<version>

Beispiele:
org.eclipse.sdk_1.1.5.jar
com.ibm.wsa_1.0.1\install.xml

Die JAR-Datei für eine Konfiguration hat die folgende interne Pfadstruktur:

install/
    configurations/
        <konfigurations-id>_<version>/
            install.xml
            (Andere optionale Dateien - siehe "Paketinformationen übersetzen")
            ("Produktdateien" - siehe "Eclipse starten")

Die JAR-Datei enthält genau einen Pfad "install/configurations/" mit genau einer Datei install.xml. Außerdem enthält sie das Verzeichnis "meta-inf/", das durch die Java-Dienstprogramme für JAR-Dateien erzeugt wird.

Das Format der Datei install.xml für Konfigurationen wird durch die folgende DTD-Datei definiert:

<?xml encoding="US-ASCII"?>

<!ELEMENT configuration (description?, url?, component*)>
<!ATTLIST configuration
    label CDATA #IMPLIED
    id CDATA #REQUIRED
    version CDATA #REQUIRED
    provider-name CDATA #IMPLIED
    application CDATA #IMPLIED
>

<!ELEMENT description (#PCDATA)>

<!ELEMENT url (update*, discovery*)>

<!ELEMENT update EMPTY>
<!ATTLIST update
    url CDATA #REQUIRED
    label CDATA #IMPLIED
>

<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
    url CDATA #REQUIRED
    label CDATA #IMPLIED
>

<!ELEMENT component EMPTY>
<!ATTLIST component
    label CDATA #IMPLIED
    id CDATA #REQUIRED
    version CDATA #REQUIRED
    allowUpgrade (true | false) "false"
    optional (true | false) "false"
>

Die Elemente und Attribute werden wie folgt definiert:

Die aktuelle Eclipse-Implementierung lässt eine Verschachtelung von Konfigurationen bzw. die Angabe von komplexeren Komponentenregeln nicht zu.

Paketinformationen übersetzen

Bestimmte Attribute in den Installationsmanifesten sind Zeichenfolgen, die über Benutzerschnittstellen angezeigt werden sollen. Um die Übersetzung zu vereinfachen, verwenden diese Attributwerte die Konvention, die für übersetzbare Attribute von "plugin.xml" definiert ist. Zeichenfolgen, die mit dem Zeichen % beginnen, werden bis zum nächsten Leerzeichen als Schlüssel für Ressourcen-IDs behandelt (ohne das Zeichen %) und in einer Eigenschaftendatei (.properties) gesucht. Die Zeichenfolge

label="%cfg Eclipse SDK for Linux"

führt zu einer Ressourcensuche in der entsprechenden Eigenschaftendatei mit dem Schlüssel "cfg". Wenn keine Eigenschaftendateien vorhanden sind oder der Schlüssel nicht zu finden ist, wird der Standardwert für die Zeichenfolge (nach %key) verwendet.

Die Eigenschaftendateien werden im Format "install_<ländereinstellung>.properties" benannt und richten sich nach den Namenskonventionen für Java-Ressourcenpakete. In JAR-Dateien für Komponenten und Konfigurationen werden sie in dasselbe Verzeichnis wie ihre entsprechende Datei "install.xml" gestellt.

Beim Zugriff auf die Ressourcenpakete kann der Code die entsprechende Landessprachenvariante des Manifests (durch die Implementierung eines Algorithmus für die Suchfunktion) auswählen und dann unter Verwendung von

ResourceBundle b;
b = new PropertyResourceBundle(properties.openStream());

ein Paket erstellen. Alternativ kann der Code aber auch die Java-Basisunterstützung verwenden und die korrekte landessprachliche Variante des Manifests wie folgt lokalisieren:

ResourceBundle b;
ClassLoader l;
l = new URLClassLoader(new URL[] {<zielverzeichnis-url>}, null);
b = ResourceBundle.getBundle("install",Locale.getDefault(),l);

Das resultierende Ressourcenpaket kann in IPluginDescriptor.getResourceString(String,ResourceBundle) verwendet werden, um dann die übersetzte Zeichenfolge für das Manifestattribut zurückzugeben.

Überlegungen zur Sicherheit

JAR-Dateien für Komponenten und Konfigurationen können mit den Java-Standarddienstprogrammen für die Sicherheit (z. B. jarsigner) mit einer Signatur versehen werden. Während der Laufzeit prüft der Aktualisierungsmanager, ob die angeforderte JAR-Datei von einem anerkannten ("gesicherten") Provider bereitgestellt wird und ob der Inhalt der JAR-Datei seit der Signatur nicht geändert wurde. Der Benutzer hat die Möglichkeit, nicht anerkannte JAR-Dateien zu akzeptieren. JAR-Dateien, die seit der Signatur geändert wurden, werden von der Eclipse-Laufzeit zurückgewiesen.

Pakete für Landessprachen erstellen

Landessprachendateien werden für jede unterstützte Ländereinstellung in einem separaten Unterverzeichnis gepackt. Die Unterverzeichnisse können im tatsächlichen Plug-in-Verzeichnis (also innerhalb des Plug-ins) definiert sein oder in separaten Plug-in-Fragmenten gepackt werden. In beiden Fällen bietet die Eclipse-Laufzeit Services, mit denen das Basisverzeichnis des Plug-ins und die Dateien für die entsprechende Ländereinstellung zu einer gemeinsamen logischen Zugriffsstruktur "verknüpft" werden können, und zwar unabhängig davon, wie sie logisch gepackt sind.

Das Packen von Landessprachendateien als Plug-in-Fragmente führt zu einer etwas komplexeren Installationsstruktur. Hauptvorteil ist die Tatsache, dass der landessprachliche Inhalt nach dem Fakt zur Basis hinzugefügt werden kann, also nicht gleichzeitig ausgeliefert werden muss. Außerdem können auf diese Weise Fragmente im Hinblick auf Funktionsaktualisierungen unabhängig von der Basis weiterentwickelt werden.

Bei der Paketerstellung für Landessprachen entstehen die folgenden alternativen Installationsstrukturen.

Paketerstellung für Landessprachen "innerhalb" des Plug-ins

install/
    plugins/
        <plugin-id>_<version>/
            (Plug-in-Dateien)
            nl/
                <ländereinstellung>/
                    (Landessprachendateien)

Beispiel:

install/
    plugins/
        mein.tolles.plug-in_1.0.1/
            plugin.xml
            meine.jar ... (enthält Klassen und Standardressourcen)
            nl/
                de_DE/
                    meine.jar ... (enthält das übersetzte Delta)

Paketerstellung für Landessprachen als Plug-in-Fragment

install/
    fragments/
        <fragment-id>_<version>/
            fragment.xml
            nl/
                <ländereinstellung>/
                    (Landessprachendateien)

Beispiel:

install/
    fragments/
        mein.tolles.deutsches_plug-in_1.0.1/
            fragment.xml
                nl/
                    de_DE/
                        meine.jar ... (enthält das übersetzte Delta)

Die Namen für die Verzeichnisse mit den Ländereinstellungen befolgen die Namenskonventionen für Java-Ländereinstellungen.

Es ist zu beachten, dass der Inhalt des Basis-Plug-ins generell immer die Standardressourcen für die Landessprache enthalten sollte, damit die Funktion auch dann sinnvoll ausgeführt wird, wenn die richtige Baumstruktur der Ländereinstellung nicht vorhanden ist (es ist also besser, wenn in der Benutzerschnittstelle statt der Ressourcen-IDs die Standardzeichenfolgen angezeigt werden).

Die Laufzeitmechanismen, das Format der Datei "fragment.xml" und die APIs für die Verwaltung von landessprachlichen Verzeichnissen und Fragmenten werden an anderen Stellen in der Dokumentation zur Eclipse-Plattform erläutert.

Pakete für zielspezifische Unterstützung erstellen

Betriebssystemspezifische Dateien sowie spezifische Dateien für Systeme mit Fenstertechnik werden für jedes unterstützte Ziel in einem separaten Unterverzeichnis gepackt. Die Unterverzeichnisse können im eigentlichen Plug-in-Verzeichnis (also innerhalb des Plug-ins) definiert sein oder in separaten Plug-in-Fragmenten gepackt werden. In beiden Fällen bietet die Eclipse-Laufzeit Services, mit denen das Basisverzeichnis des Plug-ins und die entsprechenden zielspezifischen Dateien in einer gemeinsamen logischen Zugriffsstruktur "verknüpft" werden können, und zwar unabhängig davon, wie sie logisch gepackt sind.

Das Packen von zielspezifischen Dateien als Plug-in-Fragmente führt zu einer etwas komplexeren Installationsstruktur. Hauptvorteil ist die Tatsache, dass die zielspezifische Unterstützung nach dem Fakt zur Basis hinzugefügt werden kann, also nicht gleichzeitig ausgeliefert werden muss. Außerdem können auf diese Weise Fragmente im Hinblick auf Funktionsaktualisierungen unabhängig von der Basis weiterentwickelt werden.

Bei der Paketerstellung von zielspezifischen Dateien entstehen die folgenden alternativen Installationsstrukturen.

Paketerstellung für zielspezifische Unterstützung "innerhalb" des Plug-ins

install/
    plugins/
        <plugin-id>_<version>/
            (Plug-in-Dateien)
            os/
                <betriebssystemname>/
                    (Betriebssystemspezifische Dateien)
            ws/
                <name_des_systems_mit_fenstertechnik>/
                    (Spezifische Dateien für System mit Fenstertechnik)

Beispiel:

install/
    plugins/
        mein.tolles.plug-in_1.0.1/
            plugin.xml
            meine.jar
            os/
                solaris/
                    libfoo.so
            ws/
                motif/
                    meine.jar

Paketerstellung für zielspezifische Unterstützung als Plug-in-Fragment

install/
    fragments/
        <fragment-id>_<version>/
            fragment.xml
            os/
                <betriebssystemname>/
                    (Betriebssystemspezifische Dateien)
            ws/
                <name_des_systems_mit_fenstertechnik>/
                    (Spezifische Dateien für System mit Fenstertechnik)

Beispiel:

install/
    fragments/
        mein.tolles.plug-in_solaris_1.0.1/
            fragment.xml
            os/
                solaris/
                    libfoo.so
            ws/
                motif/
                    meine.jar

Die für die Verzeichnisnamen verwendeten Zielkennungen werden durch Eclipse definiert (siehe Javadoc für org.eclipse.core.boot.BootLoader).

Die Laufzeitmechanismen, das Format der Datei "fragment.xml" und die APIs für die Verwaltung von zielspezifischen Verzeichnissen und Fragmenten werden an anderen Stellen in der Dokumentation zur Eclipse-Plattform erläutert.

Pakete für Unterstützungselemente erstellen

Zusätzliche Unterstützungsdateien können direkt in den Plug-in-Verzeichnissen oder als Fragmente gepackt werden. Hierzu können Beispiele, Referenzliteratur für Anwendungsentwickler, Anwendungsbeispiele oder andere Informationen gehören, die nicht direkt zur Bereitstellung der Basisbenutzerfunktion dienen. Im Allgemeinen gibt die Plattform Position und Verwendung dieser Dateien nicht an. Wenn diese Dateien als Fragmente gepackt sind, bietet die Plattform jedoch eine Unterstützung für den Zugriff auf den kombinierten Plug-in-/Fragmentbereich in Form einer einzigen logischen Baumstruktur. Auf diese Weise muss das Basis-Plug-in lediglich die primäre Benutzerunterstützung enthalten und stellt die zusätzlichen Informationen nur dann bereit, wenn die erforderlichen Fragmente ebenfalls vorhanden sind.

Installationsstruktur

Unterschiede zwischen Komplett- und Referenzinstallation

Eclipse unterstützt zwei Installationstypen:
  1. Als "Komplettinstallation" wird die resultierende Dateisystemstruktur bezeichnet, die nach der Ausführung des Installationsprozesses vorliegt. Die Dateien werden so im Dateisystem platziert, wie es für eine direkte Ausführung der Eclipse-Plattform erforderlich ist. Die Eclipse-Funktionen können nur aus einer Komplettinstallation direkt ausgeführt werden.
  2. Als "Referenzinstallation" wird die Dateistruktur bezeichnet, die an einer Eclipse-Aktualisierungsposition vorliegt, an der installierbare Komponenten und Konfigurationen ausgewählt werden können.

Dateisystemzuordnung: Komplettinstallation

Als Komplettinstallation wird die Ausgabe des Installationsprozesses definiert, und zwar unabhängig davon, ob dieser Prozess durch eine "herkömmliche" Installation oder durch eine Aktion des Aktualisierungsmanagers ausgelöst wurde. Aus einer Komplettinstallation kann die Eclipse-Plattform direkt ausgeführt werden.

Eine Eclipse-Komplettinstallation enthält die folgende Dateistruktur:

<stammverzeichnis_der_installation>/
    install/
        install.properties
        components/
            <komponenten-id>_<version>/
                install.xml
                install_<ländereinstellung>.properties (optional)
        configurations/
            <konfigurations-id>_<version>/
                install.xml
                install_<ländereinstellung>.properties (optional)
                (Andere "Produktdateien" - optional)

    plugins/
        <plugin-id>_<version>/
            plugin.xml
            (Andere Plug-in-Dateien)
    fragments/
        <fragment-id>_<fragment-version>/
            fragment.xml
            (Andere Fragmentdateien, kann auch plugin.xml umfassen)

Die Verzeichnisse und Dateien werden so definiert, wie dies bereits für die JAR-Dateien für Komponenten und Konfigurationen beschrieben wurde.

Die Datei "install.properties" enthält konfigurierbare Starteigenschaften. Sie gibt die aktuelle Startkonfiguration für die Plattform und die installierte Anwendung an. Ihre genaue Verwendung ist im Abschnitt "Eclipse starten" beschrieben. Diese Datei wird erstmals im Rahmen einer neuen Installation installiert. Anschließend wird sie nur dann durch den Aktualisierungsmanager aktualisiert, wenn die Eclipse-Installation aktualisiert wird. Wenn die Datei auf andere Weise so aktualisiert wird, dass sie mit der Originalinstallation nicht mehr kompatibel ist, wird der letzte gültige Status wiederhergestellt.

Die Datei hat das Format einer Java-Datei ".properties" und enthält die folgenden Angaben:

application=<anwendungs-id>
application.configuration=<konfigurations-id>_<version>
runtime=<plugin-id>_<version>

Beispiel:

application=
application.configuration=com.ibm.wsa_1.0.3
runtime=org.eclipse.core.boot_1.1.4

Die Eigenschaftendefinitionen lauten wie folgt:

Die Dateien "installation.properties" werden durch das Programm für die Erstinstallation erstellt. Sobald sie installiert wurden, können die Anwendungs- und Laufzeiteigenschaften aktualisiert werden. Nur das Versionssuffix von "application.configuration" kann aktualisiert werden (jedoch nicht die "dominante" Konfigurationskennung).

Hinweis: Wie in diesem Abschnitt angegeben, muss bei der Erstinstallation eines auf Eclipse basierenden Produkts auch die Datei "install.properties" installiert werden, die die korrekten Originaleinstellungen für den Start enthält. Erfolgt dies nicht, kann das Produkt nicht gestartet werden.

Arbeitsbereichdateien

Bei einer typischen Konfiguration für einen Einzelbenutzer enthält das <stammverzeichnis_der_installation> auch die Arbeitsbereichdateien des Benutzers. Diese Dateien werden erstellt, sobald die Plattform gestartet wurde. In einer Konfiguration mit mehreren Arbeitsbereichen wird beim Starten der Plattform ein explizites Arbeitsbereichsverzeichnis angegeben. Alle Dateien, die im Rahmen der Plattformausführung erstellt werden, werden in die Arbeitsbereichsverzeichnisse geschrieben. In einem Szenario mit mehreren Arbeitsbereichen muss der Benutzer unbedingt sicherstellen, dass jeweils nur 1 Exemplar des Aktualisierungsmanagers aktiv ist. Wenn die Konfiguration mit mehreren Arbeitsbereichen eigentlich eine Installation darstellt, die von Benutzern in einem Mehrbenutzersystem gemeinsam benutzt wird, sollte der "Administrator" der gemeinsam benutzten Installation gewährleisten, dass die einzelnen Benutzer nur einen Lesezugriff auf das Stammverzeichnis der Installation erhalten.

Dateisystemzuordnung: Referenzinstallation

Die Dateistruktur der Referenzinstallation hat Ähnlichkeit mit der Komplettinstallation. Sie enthält Folgendes:

<stammverzeichnis_der_installation>/
    install/
        components/
            install.index (optional)
            <komponenten-id>_<version>/
                install.xml
                install_<ländereinstellung>.properties (optional)
                <komponenten-id>_<version>.jar
        configurations/
            install.index (optional)
            <konfigurations-id>_<version>/
                install.xml
                install_<ländereinstellung>.properties (optional)
                <konfigurations-id>_<version>.jar

Die Referenzinstallation kann ganz einfach erstellt werden, indem das Installationsmanifest (und alle Ressourcenpakete der Installation) aus der JAR-Datei für die Komponente oder die Konfiguration teilweise dekomprimiert und dann die gesamte JAR-Datei in die resultierende Verzeichnisstruktur (als Peer für die Datei "install.xml") kopiert wird. Dadurch, dass die Datei "install.xml" erkennbar ist, kann der Aktualisierungsmanager ermitteln, welche Elemente an einem bestimmten Standort verfügbar sind. Sobald sie ausgewählt ist, wird die entsprechende JAR-Datei heruntergeladen und installiert.

Wenn auf den Standort der Referenzinstallation über ein anderes Protokoll als eine direkte Dateiein-/ausgabe zugegriffen wird, muss der Standort außerdem die optionale Datei "install.index" enthalten (in den Verzeichnissen "components/" und "configurations/"). Diese Datei ist ein einfaches "Inhaltsverzeichnis" der Verzeichnisse. Es enthält jeweils in einer separaten Zeile die tatsächlichen Unterverzeichnisnamen.

Beispiel:

<stammverzeichnis_der_installation>/
    install/
        components/
            install.index
            org.eclipse.platform_1.0.1/
            org.eclipse.jdt_2.9.5/
            org.eclipse.pde_1.0.4/

Die Datei "install.index" würde Folgendes enthalten:

org.eclipse.platform_1.0.1
org.eclipse.jdt_2.9.5
org.eclipse.pde_1.0.4

Die Datei "install.index" wird nicht benötigt, wenn auf den "Standort" über eine direkte Dateiein-/ausgabe verwiesen wird (als URL der "Datei"). Es muss jedoch beachtet werden, dass die Datei, wenn sie vorhanden ist, auch bei einem Zugriff für die direkte Dateiein-/ausgabe verwendet wird. Auf diese Weise kann die Standortverwaltung mit Hilfe dieser Datei steuern, welche Konfigurationen und Komponenten tatsächlich erkennbar sind. Dies ist im Allgemeinen dann nützlich, wenn die in Konfigurationen enthaltenen Komponenten nicht als separate Elemente heruntergeladen und installiert werden sollen (also nur über eine bestimmte Konfiguration verwaltet werden sollen). In diesem Fall wären zwar die Konfigurationen direkt erkennbar, nicht jedoch die Komponenten. Die Komponenten würden nur über die erkennbaren Konfigurationen lokalisiert.

Eclipse starten

Bevor Sie sich mit einigen Überlegungen zur Aktualisierung beschäftigen, müssen Sie zunächst wissen, wie die Eclipse-Plattform gestartet wird. Die folgenden Elemente werden beim Start verwendet:
  1. Das Stammverzeichnis der Installation enthält den Startbefehl für das "Produkt". Dies kann entweder ein einfaches Befehls-Script sein (z. B. eine Datei ".bat"), oder die Funktion des Scripts kann durch ein einfaches ausführbares Startprogramm (z. B. Datei ".exe") ausgeführt werden. In beiden Fällen führt der Startbefehl 3 Aktionen durch:
  2. An "Main" werden die Positionen der ausführbaren Ressourcen der Eclipse-Plattform (Eigenschaft "runtime") und die Kennung einer Anwendung übergeben, die die Plattform ausführen soll (Eigenschaft "application", die von Eclipse angegebene Standardanwendung ist die Workbench). "Main" sucht die Plattformdatei "boot.jar" und lädt aus dieser das Modul "BootLoader" für die Plattform. Die Steuerung wird BootLoader erteilt, indem die Kennung einer Anwendung als Argument übergeben wird (ggfs. zuzüglich weiterer Startparameter).
  3. BootLoader startet die Plattformkernlaufzeit. Hierdurch wird die Plug-in-Registrierung geladen und aufgelöst (die zur Ausführung auswählbaren Plug-ins werden konfiguriert).
  4. BootLoader sucht in der Plug-in-Registrierung nach dem in einem Argument übergebenen Anwendungsnamen. Wenn dieser gefunden wird, aktiviert BootLoader das Anwendungs-Plug-in und übergibt diesem die Steuerung.
  5. Die gestartete Anwendung (z. B. die Workbench) aktiviert und ruft andere Plug-ins wie erforderlich auf.
Hinweis: Das Standardstartprogramm, das mit der aktuellen Version der Eclipse-Plattform zur Verfügung gestellt wird, verarbeitet die Datei install.properties (wie in den Schritten 1 und 2 oben beschrieben) nicht. Es sucht lediglich nach der Standardeingangsanzeige und nach der Plattformlaufzeit für sich selbst.

Überlegungen zur Aktualisierung

Nicht zur Plattform gehörende Komponenten aktualisieren

Komponenten, die nicht zur Plattform gehören, stellen Plug-ins zur Verfügung, die zusätzlich zur Plattform ausgeführt werden. Der Aktualisierungsmanager installiert lediglich die erforderlichen Plug-in-Verzeichnisse und -Dateien. Diese werden beim nächsten Starten der Plattform gefunden und verarbeitet.

Der Aktualisierungsmanager aktualisiert in keinem Fall eine vorhandene Verzeichnisstruktur für ein Plug-in. Er installiert nur eine Version eines Plug-ins, das zuvor noch nicht vorhanden war. Falls das Plug-in-Verzeichnis bereits vorhanden ist (weil es in einer anderen Komponente oder in einer anderen Version enthalten war), wird es nicht erneut installiert. Der Aktualisierungsmanager überprüft nicht, ob der vorhandene Verzeichnisinhalt mit dem Inhalt in der JAR-Datei der Komponente übereinstimmt. Infolgedessen muss die Versionskennung des Plug-ins im Verzeichnisnamen für das Plug-in korrekt angegeben sein.

Plattform aktualisieren

Die aktuelle Version der Eclipse-Plattform lässt das Aktualisieren der Plattform über den Aktualisierungsmanager nicht zu. Plattformaktualisierungen müssen mit herkömmlichen Installationsmechanismen verarbeitet werden.

JRE aktualisieren

Die aktuelle Version der Eclipse-Plattform lässt das Aktualisieren von JRE über den Aktualisierungsmanager nicht zu. JRE-Aktualisierungen müssen mit herkömmlichen Installationsmechanismen verarbeitet werden.

Produktdateien aktualisieren

Eine als Paket vorliegende Installation enthält normalerweise eine Reihe von verschiedenen Dateien, die schließlich in das Startverzeichnis des Produkts gestellt werden. Hierzu gehören unterschiedliche Readme-Dateien, Images für Eingangsanzeigen, Kopien von Lizenzvereinbarungen, Release-Informationen usw. Diese Dateien sollten als Teil der JAR-Dateien für Komponenten und Konfigurationen gepackt werden, und zwar als willkürliche zusätzliche Dateien im spezifischen Verzeichnis der Komponente bzw. Konfiguration (als Peer für install.xml). Es sind sowohl einzelne Dateien als auch Unterverzeichnisse zulässig. Auf diese Weise werden solche Dateien als Teil der versionierten JAR-Datei für die Komponente bzw. die Konfiguration gepackt, bereitgestellt und installiert.

Eine JAR-Datei für eine Komponente kann beispielsweise Folgendes enthalten:

install/
    components/
        com.xyx.etools_1.3.5/
            install.xml
            splash.bmp
            readme.txt
            license.txt
            notes/
                jspedit.txt
                debug.txt

Startunterstützung aktualisieren

Die aktuelle Version der Eclipse-Plattform lässt das Aktualisieren des Startprogramms (.exe, startup.jar) über den Aktualisierungsmanager nicht zu. Startprogramme müssen mit herkömmlichen Installationsmechanismen aktualisiert werden.

Aktualisierungsfehler beheben

Es gibt zwei Szenarien, die eintreten können:
  1. Gesteuerte Fehler: Dies sind unterschiedliche Fehler beim Zugriff, Herunterladen, Dekomprimieren usw., die durch den Aktualisierungsmanager festgestellt werden. Der Aktualisierungsmanager enthält eine Logik, mit deren Hilfe solche Fehler behoben werden können.
  2. "Nicht gesteuerte" Fehler: Dies sind plötzlich auftretende Fehler (z. B. die Unterbrechung der Stromversorgung), die mitten im Aktualisierungsprozess auftreten, bevor die Verarbeitung des Aktualisierungsmanagers vollständig abgeschlossen werden kann. Solche Fehler werden beim Starten der Plattform festgestellt. Die Baumstruktur der Installation wird mit dem letzten bekannten Status verglichen, und alle Teiländerungen werden aus der Baumstruktur der Installation entfernt.

Falsche Aktualisierungen korrigieren

Der Aktualisierungsmanager verwaltet eine Beschreibung, die den aktuellen Konfigurationsstatus der Installation enthält. Hierzu gehört die Liste der "aktiven" Konfigurationen und Komponenten (die tatsächliche Baumstruktur der Installation kann unter Umständen zusätzliche Konfigurations- und Komponentenversionen enthalten, die als Folge von anschließenden Aktualisierungen verborgen sind).

Immer dann, wenn der Aktualisierungsmanager diese Informationen aktualisiert und speichert (die Speicherung erfolgt beim Beenden der Plattform), werden die Statusinformationen geklont, und der vorherige Status wird als chronologische Folge von Aktualisierungen beibehalten. Der Aktualisierungsmanager verwaltet mehrere Generationen dieses Statuswerts (die Anzahl der vorherigen Statuswerte kann über eine Option festgelegt werden). Alte Statusversionen sowie Versionen der entsprechenden Konfigurationen und Komponenten werden im Rahmen der Bereinigungsverarbeitung des Aktualisierungsmanagers in regelmäßigen Abständen erfasst (gelöscht).

Anhand der Kopien mit den früheren Versionen des Statuswerts kann nach falschen Aktualisierungen eine Korrektur vorgenommen werden. "Falsch" bedeutet in diesem Szenario, dass der Aktualisierungsmanager eine Änderung erfolgreich heruntergeladen und angelegt hat, die Änderung jedoch Fehler verursacht.

Installation bereinigen

Der Aktualisierungsmanager erstellt in regelmäßigen Abständen einen Ausschnitt vom Inhalt der Installationsbaumstruktur. Nur Komponenten- und Konfigurationsverweise, die in mehreren der neuesten Generationen des Aktualisierungsstatus enthalten sind, bleiben erhalten (die Anzahl der beibehaltenen Statuswerte kann über eine Option festgelegt werden). Die Bereinigung erfolgt im Rahmen der Verarbeitung des Aktualisierungsmanagers und muss nicht explizit ausgelöst werden.

Nicht verwaltete Eclipse-Funktion

Neben "formgerecht" installierten Konfigurationen und Komponenten toleriert die Eclipse-Plattform Plug-ins und Plug-in-Fragmente, die direkt in die Installationsbaumstruktur gestellt werden und nicht in einem zugeordneten Installationsmanifest beschrieben sind. Solche Plug-ins und Fragmente werden von der Laufzeit erkannt, können jedoch nicht mit den Funktionen des Aktualisierungsmanagers aktualisiert oder entfernt werden. Man spricht daher auch von "nicht verwalteten Funktionen". Diese Unterstützung ist insbesondere auf Szenarien der Plug-in-Entwicklung abgestimmt und soll versuchen, den Systemaufwand, der bei der Entwicklung von Installationen/Paketen entsteht, zu eliminieren. Herkömmliche Installationsprogramme sollten nicht verwaltete Plug-ins und Fragmente nicht installieren.

Überlegungen zur Installation

Hinsichtlich der Installation unterscheidet Eclipse zwischen einer Installation, die eine neue Basis für die Eclipse-Plattform bereitstellt (JRE, Plattform und "dominante" Anwendung), und einer Installation, die eine vorhandene Basis lediglich durch neue Komponenten ergänzt (mit diesen mischt).

Neue Installation

Gegenwärtig muss eine neue Plattforminstallation mit einer herkömmlichen Installationsmethode vorgenommen werden, wie beispielsweise dem Windows MSI-Installationsprogramm, RPM, InstallShield oder einem einfachen Archivmechanismus (z. B. komprimierte Datei). Das Installationsprogramm muss gewährleisten, dass die entstehende Dateistruktur (nach Abschluss der Installation) die in diesem Dokument beschriebenen Spezifikationen einhält.

Das Installationsprogramm muss Folgendes ausführen:

Es muss ein "herkömmliches" Deinstallationsprogramm zur Verfügung gestellt werden, um die "dominante" Anwendung und ihre Baumstruktur in der Eclipse-Plattform entfernen zu können. Im Allgemeinen ist das Deinstallationsprogramm dafür zuständig, die Aktionen seines zugeordneten Installationsprogramms zurückzunehmen. Da sich der Inhalt der Installationsbaumstruktur von Eclipse jedoch bei einer normalen Verwendung des Eclipse-Aktualisierungsmanagers ändern kann, ist es möglich, dass das "herkömmliche" Deinstallationsprogramm die anfangs installierten Dateien tatsächlich nicht finden kann. Manche Dateien sind eventuell nicht mehr vorhanden (weil sie durch den Aktualisierungsmanager entfernt wurden), und die Installationsbaumstruktur enthält möglicherweise zusätzliche Dateien, die in der Erstinstallation nicht enthalten waren (z. B. angelegte Aktualisierungen). Infolgedessen ist ein "herkömmliches" Deinstallationsprogramm, das sich ausschließlich auf das Installationsprotokoll stützt, nicht in der Lage, die Anwendungsinstallation vollständig zu entfernen.

Um Änderungen zu kompensieren, die durch den Aktualisierungsmanager vorgenommen wurden, kann das "herkömmliche" Deinstallationsprogramm das Entfernen aller Dateien in den folgenden Installationsverzeichnissen von Eclipse erzwingen:

Andere Verzeichnisse in der Installationsbaumstruktur könnten Benutzerdaten enthalten und sollten daher nicht entfernt werden.

Gemischte Installation

Sobald eine Installation der Eclipse-Plattform eingerichtet wurde (siehe vorheriger Abschnitt), können zusätzliche Komponenten und Konfigurationen zur Plattform hinzugefügt werden. Hierzu kann der Eclipse-Aktualisierungsmanager oder ein "herkömmliches" Installationsprogramm verwendet werden. Im letzteren Fall muss das Installationsprogramm gewährleisten, dass die entstehende Dateistruktur (nach Abschluss der Installation) die in diesem Dokument beschriebenen Spezifikationen einhält.

Das Installationsprogramm muss Folgendes ausführen:

Die Verwendung eines "herkömmlichen" Deinstallationsprogramms bei gemischten Installationen erfordert eine besondere Sorgfalt. Im Allgemeinen sollten Deinstallationsprogramme in keinem Fall versuchen, die tatsächlich installierten Programmdateien zu entfernen. Dies liegt daran, dass die Dateien, die ursprünglich installiert worden waren, möglicherweise nicht mehr vorhanden sind oder dass einige der installierten Dateien im Rahmen der normalen Verwendung von Eclipse aktualisiert wurden. Infolgedessen kann der Versuch, die ursprünglich installierten Dateien direkt zu entfernen, bestenfalls einwandfrei funktionieren, überhaupt keine Auswirkungen haben oder im denkbar schlechtesten Fall dazu führen, dass ein Teil der installierten Unterstützung entfernt wird, was beim nächsten Starten der Anwendung unvorhersehbare Fehler verursacht. Dieser Effekt wird zusätzlich verschlechtert, wenn Komponenten oder Plug-ins gemeinsam verwendet werden. Nur dann, wenn eine Konfiguration oder eine Komponente garantiert nicht aktualisiert wurde und mit Sicherheit nicht gemeinsam benutzt wird, können ihre Dateien direkt entfernt werden.

Besonders sorgfältig sollte auch dann vorgegangen werden, wenn Installationstechniken verwendet werden, die die oben beschriebene Steuerung des Deinstallationsprozesses (z. B. das Entfernen installierter Dateien unterdrücken) nicht zulassen. Ein Beispiel hierfür ist die Verwendung von RPM auf Linux. In solchen Fällen sollte entweder die betreffende Installationstechnik bei gemischten Installationen nicht verwendet oder die entsprechende Deinstallation niemals ausgeführt werden.

Ein "herkömmliches" Deinstallationsprogramm kann das sichere Entfernen von installierten Funktionen unterstützen, indem die "Stammverzeichnisdateien" der gemischten Installation verwendet werden. Hierbei handelt es sich um Dateien, die ggfs. als Teil der gemischten Installation installiert werden und als eine Art Anker für die entsprechenden Konfigurationen und Komponenten fungieren. Die Eclipse-Plattform stellt während des Starts das Entfernen dieser "Stammverzeichnisdateien" fest, und entfernt dann auf sichere Weise die aufgeführten Konfigurationen und Komponenten.

Hinweis: Anders als die eigentlichen Konfigurations- und Komponentendateien werden die "Stammverzeichnisdateien" bei Änderungen durch den Aktualisierungsmanager nicht berücksichtigt. Daher kann sich ein "herkömmliches" Deinstallationsprogramm darauf verlassen, dass diese Dateien immer vorhanden sind, wenn sie einmal installiert wurden.

Bei der Installation werden die "Stammverzeichnisdateien" in das Verzeichnis "install/info/" der Installationsbaumstruktur von Eclipse gestellt (als Peer für die Verzeichnisse "install/configurations" und "install/components"). Die Dateien verwenden die folgende Namenskonvention:

<kennung_der_gemischten_installation>.install

Die Eclipse-Plattform gibt das Format der Kennung nicht vor (es wird in keiner Weise interpretiert). Um das Risiko von Namensunverträglichkeiten zu verringern, wird dringend empfohlen, für die Kennung eine Namenskonvention zu verwenden, die auf dem Namen der Internet-Domäne des Providers beruht (z. B. com.xyz.toolpack.install).

Der Inhalt der "Stammverzeichnisdateien" verwendet das Format von Java-Eigenschaftendateien (.properties) und enthält Folgendes:

configurations=[<konfigurations-id>_<version> [,<konfigurations-id>_<version>]* ]
components=[<komponenten-id>_<version> [,<komponenten-id>_<version>]* ]

Hierbei gilt:
[] = Optionales Element
* = Wiederholende Gruppe

(Beide Eigenschaften bestehen aus einer durch Kommata untergliederten Liste der entsprechenden Kennungen, die jeweils ein Versionssuffix haben.)

Plattformspezifische Registrierung

Hinweis: Dieser Abschnitt beschreibt eine empfohlene Methode. Zur korrekten Ausführung der Eclipse-Plattform muss diese Methode jedoch nicht unbedingt angewendet werden.

Es empfiehlt sich, dass alle auf Eclipse basierenden Produkte einen Registrierungsmechanismus des Betriebssystems verwenden, um alle Positionen der installierten Eclipse-Plattformen protokollieren zu können. Auf diese Weise ist eine einfache Suche möglich, wenn Sie bestimmen müssen, ob eine neue Plattforminstallation erstellt werden soll oder Komponenten in eine vorhandene Installation gemischt werden sollen. Auf Plattformen, bei denen ein solcher Registrierungsmechanismus nicht zur Verfügung steht, wird der Benutzer aufgefordert, die Installationsverzeichnisse für Eclipse explizit anzugeben.

Das Installationsprogramm bietet in der Regel die Auswahl zwischen dem Erstellen einer neuen Installation oder dem Mischen der Komponenten in eine vorhandene Installation. Bei der Erstellung einer neuen Installation sollten auch die Registrierungsstrukturen aktualisiert werden.

Unter Windows wird zu diesem Zweck die Windows-Registrierung verwendet. Zur Angabe der Installationsverzeichnisse für Eclipse in der Registrierung wird die folgende Schlüsselstruktur empfohlen:

eclipse.org/
    platforms/
        <produktname>

Der Schlüssel <produktname> gibt den Provider und/oder die dominante Anwendung an, der/die die neue Installation der Eclipse-Plattform erstellt hat. Dem vollständigen Schlüssel werden die folgenden Attribute zugeordnet:

label = Anzeigbare Bezeichnung des Schlüssels <produktname>. Er wird zum Erstellungszeitpunkt lokalisiert.
directory = <Absoluter Pfad>

Überlegungen zur Entwicklung

Unabhängigkeit von Installationsposition

Über die Eclipse-API kann ein aktives Plug-in einen Verweis auf sein Installationsverzeichnis abrufen. Dies wird durch einen Aufruf der Methode IPluginDescriptor.getInstallURL() erreicht. Der Aufruf gibt java.net.URL zurück. Aktive Plug-ins greifen auf alle benötigten Ressourcen unter Bezug auf diese URL zu. Die URL-Protokollunterstützung verarbeitet die erforderliche Umleitung in das lokale Plug-in-Verzeichnis, den Plug-in-Cache, auf CD (Minimalinstallation) oder den Server. Ein Plug-in greift normalerweise auf seine Ressourcen zu, indem es einen Eingabedatenstrom auf der URL öffnet und den Inhalt der Ressource liest. Da davon ausgegangen wird, dass die Installationsposition nur im Lesezugriff zur Verfügung steht, sollte das aktive Plug-in in keinem Fall versuchen, unter Verwendung der zurückgegebenen URL eine Schreiboperation auszuführen.

Native ausführbare Ressourcen

Native Java-Bibliotheken, die durch Eclipse-Plug-ins verwendet werden, erfordern keine Sonderverarbeitung. Sie werden als Teil der Verzeichnisstruktur des Plug-ins installiert und durch das Ladeprogramm für Plattformklassen (jdk 1.2+) geladen.

Betriebssystemspezifische native Komponenten (z. B. ActiveX) erfordern eine angepasste Installation, die durch den Aktualisierungsmanager von Eclipse nicht verarbeitet werden kann. Das Programm für die angepasste Installation registriert die Komponenten mit den entsprechenden Betriebssystemfunktionen und aktualisiert alle Standardsuchpfade. Die Eclipse-Plattform bietet keine automatische Prüffunktion für erforderliche native Komponenten. Die benötigte Logik für die Überprüfung/Fehlerbehebung muss vom Plug-in-Code selbst implementiert werden. Es ist möglich, ein Plug-in für "Markierungen" als Teil des Programms für die angepasste Installation zu erstellen, um das Vorhandensein von nativen Komponenten anzugeben und anderen Plug-ins die Angabe der Abhängigkeit zu ermöglichen. Dieser Ansatz ist jedoch nicht "idiotensicher" und kann keine absolute Garantie für die Erfüllung einer nativen Abhängigkeit bieten.

Unterstützung von parallelen Plug-in-Versionen

Auf der Eclipse-Plattform können gleichzeitig mehrere Versionen eines Plug-ins installiert sein. Auf diese Weise werden Szenarien ermöglicht, in denen ein Benutzer zwei auf Eclipse basierende Produkte installiert, die unterschiedliche Versionen desselben Plug-ins enthalten. Beide Versionen können im produktübergreifenden Programmstammverzeichnis installiert werden. Abhängig von den (weiter unten erläuterten) Konfigurationsregeln verwendet die Plattform während der Ausführung für gewöhnlich die neueste Version des Plug-ins. Wenn der Benutzer anschließend jedoch eines der Produkte deinstalliert, bleibt die Installationsstruktur des anderen Produkts unverändert, enthält also die korrekte Version des Plug-ins, das zusammen mit dem Produkt installiert wurde.

Außerdem können auf der Eclipse-Plattform mehrere Versionen desselben Plug-ins gleichzeitig konfiguriert sein und ausgeführt werden. Dies ist insbesondere bei Plug-ins praktisch, die gemeinsam benutzte Laufzeitbibliotheken enthalten. Es kann sein, dass ein bestimmter Benutzer der gemeinsamen Laufzeit eine Abhängigkeit von einer spezifischen Version des Plug-ins angeben will. Solch ein Plug-in muss lediglich seine Laufzeitbibliotheken (Abschnitt <runtime> der Datei "plugin.xml") deklarieren, und darf keine anderen Ergänzungen für die Plattform deklarieren (insbesondere dürfen keine Erweiterungspunkte deklariert und/oder Erweiterungen ergänzt werden).

Um dies zu unterstützen, definiert die Eclipse-Plattform ein Schema für das Angeben von Plug-ins, eine Namenskonvention für Plug-in-Verzeichnisse im Dateisystem sowie eine Reihe von Regeln für die Konfiguration und Ausführung von Plug-ins, die beim Plattformstart gefunden wurden.

Plug-ins werden durch die Kombination einer strukturierten Zeichenfolge, die Ähnlichkeit mit einem Java-Paketnamen hat, mit einer mehrstelligen Versionskennung angegeben. Die Versionskennung besteht aus einer Hauptkomponente, die eine inkompatible Generation angibt, sowie einer untergeordneten Komponente, die eine kompatible Entwicklung des Plug-ins angibt.

Da mehrere Versionen desselben Plug-ins physisch in demselben Dateibaum installiert sein können, müssen die Verzeichnisse der einzelnen Plug-ins eindeutig gekennzeichnet werden, damit sich mehrere Versionen desselben Plug-ins nicht versehentlich überlagern. Der empfohlene Name für ein Plug-in-Verzeichnis besteht aus der eindeutigen Kennung des Plug-ins, die mit der Versionskennung kombiniert wird. Zur Abgrenzung der Versionszeichenfolge von der Namenszeichenfolge wird das Unterstreichungszeichen (_) verwendet. Es folgen zwei Beispiele für Verzeichnisnamen von entsprechenden Plug-ins:
 
Plug-in Version Empfohlener Verzeichnisname
org.eclipse.ui 1.3.17 org.eclipse.ui_1.3.17
edu.xyz.tools 1.0.1 edu.xyz.tools_1.0.1

Die Plattform stellt eine API für das Arbeiten mit Versionskennungen zur Verfügung.

Es gibt eine weitere Überlegung zu Plug-ins, die eine gleichzeitige Ausführung zulassen und außerdem Plug-in-Status oder Arbeitsdaten schreiben (siehe "Plugin.getPluginStateLocation()" und "IProject.getPluginWorkingLocation(IPluginDescriptor)"). Über die Aspekte der Versionsmigration hinaus (siehe nächster Abschnitt) sind die Plug-ins auch für die Verwaltung des gleichzeitigen Zugriffs aus mehreren aktiven Versionen desselben Plug-ins auf gemeinsam benutzte Ressourcen des Plug-ins zuständig. Die Plug-ins müssen Funktionen der ausgewählten Dateizugriffs-APIs verwenden, um den gleichzeitigen Zugriff zu koordinieren.

Versionsmigration

Auf Grund der dynamischen Natur der Plattformkonfiguration müssen Plug-in-Implementierungen Migrationsprobleme berücksichtigen, die während der Ausführung auftreten könnten. Anders als herkömmliche Produkte werden auf Eclipse basierende Lösungen erst dann wirklich "zusammengeführt", wenn der Benutzer die Plattform startet.

Die Plattform enthält Basisfunktionen, mit denen ein Plug-in alle Migrationssituationen verarbeiten kann. Letztendlich ist jedoch der Plug-in-Entwickler dafür verantwortlich, dass diese Funktionen korrekt genutzt werden.

Wenn Plug-ins ausgeführt werden, können sie Plug-in-spezifische Informationen in unterschiedliche Arbeitspositionen schreiben. Verweise auf die Arbeitspositionen werden mit den folgenden API-Aufrufen abgerufen:

Jedes Plug-in ist für die Verarbeitung der Migration seiner Arbeitsdaten selbst verantwortlich. Hierbei müssen Plug-ins zwei Basisszenarien berücksichtigen:
  1. Vorwärtsmigration: Eine neue Version eines Plug-ins wurde konfiguriert und muss die Daten migrieren, die durch die vorherige Version geschrieben wurden. Diese Migration basiert auf der Annahme, dass die Version n+1 eines Plug-ins Daten lesen kann, die durch die Version n desselben Plug-ins geschrieben wurden.
  2. Rückwärtsmigration: Eine Version eines Plug-ins, die bei einem früheren Aufruf der Plattform konfiguriert wurde, wird entfernt, und eine ältere Version desselben Plug-ins wird konfiguriert (die neuere Version hatte bislang die ältere Version verborgen). Dieses Szenario ist problematischer, weil nicht generell davon ausgegangen werden kann, dass die Version n eines Plug-ins Daten lesen kann, die durch die Version n+1 des Plug-ins geschrieben wurden.
Bei einer Vorwärtsmigration muss die neue Version des Plug-ins die Daten erkennen, die durch die vorherige Version geschrieben wurden, diese Daten lesen, konvertieren und erneut schreiben. Dies kann bei der erstmaligen Aktivierung des neuen Plug-ins (Plugin.startup()) oder beim Zugriff auf die Arbeitsbereiche erfolgen. Im Allgemeinen ist die erste Methode besser zur Migration der Daten für den Plug-in-Status geeignet. Die zweite Methode eignet sich besser zur Migration der Projektdaten.

Bei der Rückwärtsmigration muss der Plug-in-Entwickler zusätzliche Arbeitsschritte ausführen. Im Grunde genommen muss die Version n+1 eines Plug-ins Daten so schreiben, dass die Version n diese Situation zumindest erkennen kann. Es gibt mehrere mögliche Methoden, mit denen Plug-ins ein solches Szenario handhaben können.

Der Plug-in-Entwickler muss dafür sorgen, dass die geeignete Implementierungsstrategie ausgewählt wird. Die Plattform enthält keine spezifischen APIs, mit denen die Migration von Plug-in-Daten automatisch verwaltet werden könnte.