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:
-
Herkömmliche Installation eines neuen Produkts
In diesem Szenario wird das Paket eines mit Eclipse erstellten
Programms mit Hilfe der plattformspezifischen Technologie für
Installationsfunktionen erstellt, wie dem
Windows-MSI-Installationsprogramm, RPM, InstallShield oder einem
einfachen Archivierungsmechanismus (z. B. eine Datei .zip).
Das Produktpackprogramm befolgt die Eclipse-Konvention für den
Dateiaufbau, die an späterer Stelle noch erläutert wird (siehe
"Dateisystemzuordnung: Komplettinstallation").
Während der Installation wird im lokalen Dateisystem eine Baumstruktur
für die neue Produktinstallation erstellt, und das
Installationsprogramm kopiert die Paketdateien.
Dieses enthält eine Kopie der Eclipse-Plattform, optional die
JRE-Umgebung für Java und alle Produkt-Plug-ins, die zusätzlich zur
Eclipse-Plattform ausgeführt werden.
-
Herkömmliche gemischte Installation
In diesem Szenario wird das Paket eines mit Eclipse erstellten
Programms mit Hilfe der plattformspezifischen Technologie für
Installationsfunktionen erstellt, wie dem
Windows-MSI-Installationsprogramm, RPM,
InstallShield oder einem einfachen Archivierungsmechanismus (z. B. eine Datei .zip).
Das Produktpackprogramm befolgt die Eclipse-Konvention für den
Dateiaufbau, die an späterer Stelle noch erläutert wird
(siehe "Dateisystemzuordnung: Komplettinstallation").
Während der Installation stellt das Installationsprogramm fest, dass
auf dem System des Benutzers bereits eine auf Eclipse basierende
Installation vorhanden ist (siehe Abschnitt "Plattformspezifische
Registrierung").
Das Installationsprogramm bietet dem Benutzer die Möglichkeit an, die
neuen Funktionen in die vorhandene Installation zu mischen (die
Alternative wäre das im vorherigen Szenario beschriebene Installieren
der neuen Funktionen als neue Installation).
Bei einem einfachen Archiv wählt der Benutzer, der die Installation
vornimmt, das vorhandene Installationsverzeichnis manuell aus
(hierbei wird er durch das Archivierungsdienstprogramm, z. B. zip,
nicht unterstützt).
-
Komponenten aktualisieren
Die Standardversion der Eclipse-Workbench enthält einen Dialog,
über den bereits installierte Komponenten über das Netz aktualisiert
werden können.
Anhand der in allen Komponentenpaketen enthaltenen Metadaten kann der
Assistent die Position des Aktualisierungsservers ermitteln.
Die Eclipse-Plattform muss erneut gestartet werden, damit die
Aktualisierung aktiviert wird.
-
Neue Komponenten hinzufügen
Die Standardversion der Eclipse-Workbench enthält einen Dialog,
über den neue Komponenten "aufgespürt" und über das Netz
hinzugefügt werden können. Die Eclipse-Plattform muss erneut
gestartet werden, damit neu hinzugefügte Komponenten aktiviert werden.
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:
-
<component>: Definiert die Komponente.
-
label: Eine optional angezeigte Bezeichnung (Name).
-
id: Erforderliche Komponentenkennung (z. B. org.eclipse.platform).
-
version: Erforderliche Komponentenversion (z. B. 1.0.3).
-
provider-name: Optionale Anzeigenbezeichnung für das Unternehmen, das
diese Komponente bereitstellt.
-
<description>: Kurzbeschreibung der Komponente.
-
<url>: Optionale URL, die Sites mit Komponentenaktualisierungen
oder neuen Komponenten angibt.
-
<update>: URL für Aktualisierungen dieser Komponente.
-
url: Tatsächliche URL.
-
label: Anzeigbare Bezeichnung (Name) für die Site, auf die verwiesen
wird.
-
<discovery>: URL für neue Komponenten oder Konfigurationen. Ein
Provider kann mit diesem Element generell auf seine eigene(n) Site(s)
oder die Site(s) von Partnern verweisen, die ergänzende Komponenten
oder Konfigurationen anbieten.
Eclipse verwendet dieses Element einfach zur Verteilung neuer
Site-URLs an die Clients.
-
url: Tatsächliche URL.
-
label: Anzeigbare Bezeichnung (Name) für die Site, auf die verwiesen
wird.
-
<plugin>: Gibt das enthaltene Plug-in an.
-
label: Optionale anzeigbare Bezeichnung (Name) des enthaltenen
Plug-ins.
-
id: Erforderliche Plug-in-Kennung.
-
version: Erforderliche Plug-in-Version. Die Versionskennung befolgt
das Format, das durch Eclipse für Versionskennungen definiert ist
(weitere Informationen finden Sie im Javadoc
der Klasse "PluginVersionIdentifier").
-
<fragment>: Gibt das enthaltene Plug-in-Fragment an.
-
label: Optionale anzeigbare Bezeichnung (Name) des enthaltenen
Plug-in-Fragments.
-
id: Erforderliche Kennung des Plug-in-Fragments. Die Kennung des
Basis-Plug-ins ist Teil der Fragmentkennung
(z. B. "org.eclipse.platform_de_DE" als Kennung für die als Fragment
gepackte deutsche Übersetzung der Plattform).
-
version: Erforderliche Version des Plug-in-Fragments. Die
Versionskennung befolgt das Format, das durch Eclipse für
Versionskennungen definiert ist (weitere Informationen finden Sie im
Javadoc der Klasse "PluginVersionIdentifier").
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:
-
<configuration>: Definiert die Konfiguration.
-
label: Eine optional angezeigte Bezeichnung (Name).
-
id: Erforderliche Konfigurationskennung (z. B. org.eclipse.sdk).
-
version: Erforderliche Konfigurationsversion (z. B. 1.0.3).
-
provider-name: Optionale Anzeigenbezeichnung für das Unternehmen, das
diese Konfiguration bereitstellt.
-
application: Optionales Attribut mit der Kennung einer Erweiterung,
die am Eclipse-Erweiterungspunkt für Anwendungen registriert ist.
Wenn kein Wert angegeben wird, wird als Standardwert für die Kennung
die Standardanwendung der Eclipse-Workbench verwendet.
Dies ist die Anwendung, die gestartet wird, wenn die sie enthaltene
Konfiguration die installierte "Hauptanwendung" darstellt.
-
<description>: Kurzbeschreibung der Konfiguration.
-
<url>: Optionale URL, die Sites mit
Konfigurationsaktualisierungen angibt.
-
<update>: URL für Aktualisierungen dieser Konfiguration.
-
url: Tatsächliche URL.
-
label: Anzeigbare Bezeichnung (Name) für die Site, auf die
verwiesen wird.
-
<discovery>: URL für neue Komponenten oder Konfigurationen. Ein
Provider kann mit diesem Element generell auf seine eigene(n) Site(s)
oder die Site(s) von Partnern verweisen, die ergänzende Komponenten
oder Konfigurationen anbieten.
Eclipse verwendet diese Element einfach zur Verteilung neuer
Site-URLs an die Clients.
-
url: Tatsächliche URL.
-
label: Anzeigbare Bezeichnung (Name) für die Site, auf die
verwiesen wird.
-
<component>: Gibt die konfigurierte Komponente an.
-
label: Optionale anzeigbare Bezeichnung (Name) der konfigurierten
Komponente.
-
id: Erforderliche Komponentenkennung.
-
version: Erforderliche Komponentenversion.
-
allowUpgrade: Optionales Attribut, Standardwert ist "false". Gibt für
den Aktualisierungsmanager an, ob die Konfiguration einen Upgrade der
Komponente auf eine neue untergeordnete Version derselben Komponente
zulässt (true) oder nur Funktionsaktualisierungen erlaubt (false).
Eine Konfiguration lässt den Upgrade einer Komponente auf eine neue
Hauptversion in keinem Fall zu.
Bei einer solchen Änderung müsste zuvor die Konfiguration
aktualisiert werden.
-
optional: Optionales Attribut, Standardwert ist "false". Gibt für den
Aktualisierungsmanager an, ob diese Komponente immer im Rahmen dieser
Konfiguration installiert werden muss (false) oder ob sie aus der
Installation ausgeschlossen (abgewählt) werden kann (true).
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:
-
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.
-
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:
-
application: Die Kennung der auszuführenden Anwendung. Dies ist die
Kennung einer Erweiterung, die
am Erweiterungspunkt "org.eclipse.core.runtime.applications"
registriert ist.
Es handelt sich um den tatsächlichen Anwendungscode, der durch die
Plattform gestartet wird.
Wenn für diese Eigenschaft kein Wert angegeben wird, wird
standardmäßig die von Eclipse bereitgestellte Workbench verwendet.
-
application.configuration: Der Verzeichnisname (in der Baumstruktur
"install/configurations/") für die Konfiguration, die zu dieser
Anwendung gehört.
Das Verzeichnis kann beliebige anwendungsspezifische Startdateien (z.
B. ein Image für die Eingangsanzeige) enthalten.
Auf diese Weise kann das Startprogramm die korrekte Version der
Dateien auswählen, die beim Start verwendet werden muss.
-
runtime: Der Verzeichnisname (in der Baumstruktur "plugins/") für die
Position der Datei "boot.jar" der Eclipse-Plattform.
Auf diese Weise kann das Startprogramm die korrekte Version der
auszuführenden Plattform auswählen.
Der Aktualisierungsmanager legt diesen Wert bei jeder Aktualisierung
der Plattform fest.
Wenn die Plattform durch eine herkömmliche Installation aktualisiert
wird, muss diese Eigenschaft korrekt festgelegt werden.
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:
-
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:
-
Die Datei "install.properties" wird gelesen (der Inhalt dieser Datei
wurde bereits erläutert).
Das Image für die Eingangsanzeige wird im Verzeichnis mit der
Anwendungskonfiguration
(application.configuration) gelesen und angezeigt.
-
Die auszuführende JVM wird ausgewählt und gestartet (entweder über den
Java-Befehl oder durch das direkte Laden der ausführbaren
JVM-Dateien).
Die JRE-Auswahlkriterien enthalten eine explizit übergebene
JRE-Position, eine relative Position für das Startprogramm oder eine
Einstellung für die Umgebungsvariable (gemeinsame Benutzung einer
allgemeinen JRE auf dem System).
-
Die Klasse "Main" aus der Datei "startup.jar" wird geladen und ihre
Methode "main(...)" wird ausgeführt.
-
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).
-
BootLoader startet die Plattformkernlaufzeit. Hierdurch wird die
Plug-in-Registrierung geladen und aufgelöst (die zur Ausführung
auswählbaren Plug-ins werden konfiguriert).
-
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.
-
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:
-
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.
-
"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:
-
Stammverzeichnis für die neue Installation der Eclipse-Plattform
einrichten.
-
Stammverzeichnis der neuen Plattform ggfs. in der entsprechenden
betriebssystemspezifischen Registrierung eintragen.
-
Kopie von JRE (Java Runtime Environment - Java-Laufzeitumgebung)
installieren bzw. sicherstellen, dass eine vorhandene JRE für die
Verwendung mit Eclipse ordnungsgemäß konfiguriert ist.
-
Eclipse-Plattform installieren (mindestens die Komponenten
"org.eclipse.core" und "org.eclipse.ui").
-
Konfiguration der "dominanten" Anwendung installieren. Normalerweise
umfasst dies die gesamte Anwendungskonfiguration zuzüglich aller
erforderlichen Komponenten (und ihren entsprechenden Plug-ins und
Fragmenten).
Mindestens erforderlich ist eine "Platzhalterkonfiguration" für die
Anwendung, die eine Aktualisierungsposition angibt, in der sich die
tatsächliche Anwendungsfunktion befindet (bitte beachten Sie, dass
der Benutzer in der aktuellen Implementierung das
Herunterladen/Aktualisieren nach dem Start von Eclipse explizit
auslösen muss).
-
Ausgangsdateien "install.properties" wie zuvor beschrieben
installieren (Konfigurationseinstellungen für Systemstart).
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:
-
install/: Dieses Verzeichnis enthält die Konfigurationsdaten für die
Installation (keine Benutzerdaten).
-
plugins/: Dieses Verzeichnis enthält ausführbare Dateien usw. (keine
Benutzerdaten).
-
fragments/: Dieses Verzeichnis enthält ausführbare Dateien für
Plug-in-Fragmente usw. (keine Benutzerdaten).
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:
-
Position einer installierten Eclipse-Plattform automatisch ermitteln
(auf Systemen, die einen Registrierungsmechanismus - siehe unten -
unterstützen) oder vom Benutzer die Eingabe einer solchen Position
anfordern.
-
Geeignete Konfigurationen und Komponenten installieren (zusammen
mit den entsprechenden Plug-ins und Fragmenten).
-
Ggfs. eine "Stammverzeichnisdatei" für eine gemischte Installation
speichern, die im Rahmen der "herkömmlichen" Deinstallation benötigt
wird (siehe unten).
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.
-
id: Die eindeutige Kennung für das Plug-in. Es handelt sich um eine
strukturierte Zeichenfolge, die Ähnlichkeit mit einem Java-Paketnamen
hat.
Das Kennzeichnungsschema vermeidet Namensunverträglichkeiten durch
eine einfache hierarchische Namenskonvention, die auf den
registrierten Namen der Internet-Domänen der jeweiligen
Plug-in-Hersteller basiert.
Gültige Beispiele für eindeutige Plug-in-Kennungen sind
"org.eclipse.ui" und "edu.xyz.tools".
-
version: Eine mehrstellige Kennung. Sie befolgt die Definition, die
für die Klasse "PluginVersionIdentifier"
beschrieben ist
(hauptkomponente.untergeordnete_komponente.aktualisierung).
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.
-
IPluginDescriptor.getVersionIdentifier(): Gibt die Versionskennung
für ein spezifisches Plug-in zurück.
-
Klassenimplementierung von PluginVersionIdentifier: Methoden für diese
Klasse ermöglichen den Zugriff auf die übergeordnete und die
untergeordnete Komponente der Kennung.
Außerdem implementieren sie einen Abgleich für Gleichwertigkeit und
Kompatibilität einer Version.
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:
-
Plugin.getPluginStateLocation(): Gibt die plattformweite Position des
Betriebsstatus für das Plug-in zurück.
-
IProject.getPluginWorkingLocation(IPluginDescriptor): Gibt die
Arbeitsposition des Plug-ins im Projekt zurück, auf das verwiesen
wird.
Jedes Plug-in ist für die Verarbeitung der Migration seiner
Arbeitsdaten selbst verantwortlich.
Hierbei müssen Plug-ins zwei Basisszenarien berücksichtigen:
-
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.
-
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.
-
Das inkompatible Datenformat wird erkannt und "kulanterweise"
verarbeitet (die Erkennung kann über die Versionsmarke der Daten oder
durch Empfang eines Datenfehlers beim Lesevorgang erfolgen).
Wenn die Plug-in-Daten nicht gelesen werden können, werden sie auf
ein anfängliches Standardverhalten zurückgesetzt (so, als ob der
vorherige Status nicht gefunden worden wäre).
Der Nachteil dieser Methode ist, dass Daten (z. B.
Plug-in-Einstellungen) verloren gehen können.
-
Die Version n+1 schreibt alle Basisinformationen unter Verwendung des
Formats von Version n und erstellt separate (durch n nicht erkannte)
Dateien für alle erweiterten Informationen.
Die Version
n+1 muss tolerieren, dass die Basisdateien und die
Erweiterungsdateien nicht mehr synchron sind (Version n+1 wurde auf
Version n migriert und anschließend wieder auf Version n+1 migriert).
-
Es wird ein sich selbst beschreibendes Format für die
Serialisierung verwendet, das den Basisinhalt und versionsspezifische
Erweiterungen angibt.
Diese Erweiterungen können zusätzliche Qualifikationsmerkmal enthalten
(z. B. "Ignorieren, falls nicht verständlich", "Muss verstanden
werden" usw.).
Die Version n eines Plug-ins kann Daten lesen die durch die Version
n+1 geschrieben wurden (Modulo aller Regeln für
Qualifikationsmerkmale).
Falls Version n einen Teil der Basisdaten aktualisiert, schreibt es
die Datei erneut, wobei die Erweiterungen aus der Version n+1
erhalten bleiben.
Erweiterungen, die verstanden werden müssen, werden nicht erneut
geschrieben.
Die Version n+1 muss tolerieren, dass der Basisinhalt und die
Erweiterungen nicht mehr synchron sind (Version n+1 wurde auf
Version n migriert und anschließend wieder auf Version n+1 migriert).
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.
