Begriffe zum Equinox P2 Provisioning

Mit der Einführung des Equinox P2 Frameworks und Ablösung des Eclipse Update Manager wurde ein völlig neues Konzept für das Provisioning umgesetzt. Um den Einstieg zu erleichtern sind im folgenden einige Begriffe ausführlich erklärt.

Agent: Hinter dem Begriff Agent verbirgt sich das Konzept aus Zusammenspiel von Director, Repositories, Engine und Touchpoints. Der Agent ist dabei rein fiktiv und nicht als Objekt vorhanden. Die Funktion eines Agenten kann eine RCP Applikation für sich selber erfüllen, aber es kann auch eine andere unabhängige Applikation sein.
Artefact: Artefakte sind die Bundle JARs, also die Pakete die installiert werden. Artefacts befinden sich im Artefact Repository. Auch das Installationsverzeichnis einer Eclipse Installation fungiert als Artefact Repository. Die zu Verfügung stehenden Artefacte sind im artefact.xml (bzw artefact.jar) aufgeführt.
Bundle Pool: Ein Bundlepool ist üblichweise ein Verzeichnis mit Plugins (Bundles). Diese können in verschiedenen Versionen vorliegen. Bei einem Shared Bundle Pool teilen sich mehrere Appliationen diesen Bundle Pool.
Director: Der Director ist die zentrale Komponente eines Installationsvorganges. Er lässt über den Planner aus den Metadaten die nötigen Systemänderungen (Provisioning Operations) ermitteln und startet dann die Engine um die noch benötigten ermittelten Artefakte aus den remoten Repositories herunter zuladen und die Änderungen im Profil der RCP Anwendung auszuführen. siehe » Director Application
Dropins-Verzeichnis: Mit der Einführung von p2 dient das Pluginverzeichnis einer Eclipseinstallation automatisch als Bundlep Pool und damit auch als Artefact Repository.
War es früher üblich Plugins durch das einfache Kopieren in das Pluginverzeichnis einer Eclipse IDE hinzuzufügen sollte seit Eclipse 3.4 das Dropin-Verzeichnis dazu verwendet werden. Plugins, die in das Dropins-Verzeichnis kopiert werden, werden automatisch in der Eclipse IDE installiert. Unter Eclipse 3.5.1 gilt dies jedoch auch noch für die Plugin-Verzeichnis.
Engine: Die Engine führt die durch den Director aus den Metadaten als nötig ermittelten Änderungen an der Installation der RCP Applikation aus. Zum Beispiel werden nicht mehr benötigte Bundels aus dem Profil (aber nicht aus dem Bundle Pool!) entfernt. Noch nicht vorhandene Artefakte werden aus dem Repository in den Bundle Pool der RCP Applikation geladen. Änderungen von Programm und JVM Argumente werden in den entsprechenden Konfigurationdateien (eclipse.ini, launcher.ini) gesetzt. Der Ausführungsprozess der Engine ist dabei in mehrere Phasen unterteilt, so dass die einzelnen Aktionen koordiniert ausgeführt werden können. Als Default Phasen gibt es collect, unconfigure, uninstall, property, check trust, install, configure. Die Ausführung der Systemänderung wird an eine zuständige Touchpoint Action delegiert.
Metadata - Installable Units(IU): Die Metadaten befinden sich in einem Metadaten Repository und bestehen im Grunde aus einer xml Datei in welcher alle installierbaren Einheiten, die so genannten Installabel Units (IU), mit ihren Abhängigkeiten zueinander aufgelistet sind. Eine Installable Unit kann zum Beispiel ein Bundle (Plugin) oder auch ein zusammenfassendes Feature beschreiben. Gekennzeichnet ist eine IU analog zu Bundles durch eine id und einer Versionsnummer, die global eindeutig sein muss. Die Beschreibung enthält den Namen, Version, die bereit gestellten und die benötigten Capabilities (Provides and Required Capabilities), sowie Touchpoint-Anweisungen.
Die Trennung von Metadaten und Artefakten ermöglicht es, die Ermittlung von Abhängigkeiten unabhängig von den Artefakten durchzuführen. Ein Artefakt muss also nicht lokal vorhanden sein um aus den Metadaten zuermitteln welche anderen Artefakte es benötigt. Soll ein Product installiert werden, so ist dessen IU Ausgangsbasis für die Ermittlung aller Abhängigkeiten. Aufgeführt sind zum Beispiel alle IUs welche die benötigten Features beschreiben, die wiederum haben Abhängigkeiten zu einer Reihe von Plugins.
Planner: Der Planner ist zuständig für die Ermittlung welche Provisioning-Operationen duchgeführt werden müssen um eine Applikation so zu verändern, damit sie dem neuen gewünschten Zustand entspricht. Ausgangsbasis für die Ermittlung ist das aktuelle Profil welches den Ist-Zustand beschreibt. Bei einer Neuinstallation ist das Profil leer bzw nicht vorhanden. Der Applikation sollen nun IUs hinzugefügt und/oder entfernt werden. Das Profil soll sich also in diese Richtung verändern. Anhand der Metadaten ermittelt der Plannern nun welche Provisioning-Operationen durchgeführt werden müssen.
Profile: Der Istzustand einer RCP Applikation wird durch ein Profil in der Profil Registry beschrieben. Das Profil enthält die Metadaten aller installierten IUs welche die Applikation ausmachen. Damit ist es möglich zu ermitteln welche IUs zu der durch das Profil repräsentierten RCP Applikation gehören und welche Provisioning-Operationen bei einer Entfernung aus der Applikation ausgeführt werden müssen. Teilen sich mehrere Applikation ein Bundle Pool muss jede ein eigenes Profil besitzen. Eine IU eines Artefakts aus dem Bundle Pool kann in einem oder mehreren Profilen aus der Profil Registry vorkommen oder aber wenn es deinstalliert wurde in keinem.
Touchpoint: Die Installation einer Software ist abhängig von seiner Umgebung. Das Interface zwischen der Engine und dem Zielsystem bilden die Touchpoints. Ein Touchpoint ermöglicht die Ausführung einer Provisioning-Operation auf dem Zielsystem. Der Eclipse Touchpoint übernimmt die Aufgabe die Bundles in die Equinox Platform zu integrieren. Für unterschiedlichen Betriebssysteme gibt es zudem Native Touchpoints, die zum Beispiel das Entzippen von Dateien oder die Rechtevergabe von Verzeichnissen ermöglichen falls das Betriebssystem ies unterstützt.

	Equinox P2 Provisoning RCP Anwendungsentwicklung mit Eclipse
Eclipse RCP Examples Eclipse.org Eigene Preferences Equinox P2 P2 Begriffe Director Application P2 Remote Debuggen Informationen Icons Interessante Links RCP Bücher OSGI Bücher Web Entwicklung Dynamik mit Ajax Bookmarklet Suchergebnisvorschau Firefox Add-ons About About Weitere Links Silke in Amerika Silke in Australien Silke in Europa Reisen und Fotos	Begriffe zum Equinox P2 Provisioning Mit der Einführung des Equinox P2 Frameworks und Ablösung des Eclipse Update Manager wurde ein völlig neues Konzept für das Provisioning umgesetzt. Um den Einstieg zu erleichtern sind im folgenden einige Begriffe ausführlich erklärt. Agent Hinter dem Begriff Agent verbirgt sich das Konzept aus Zusammenspiel von Director, Repositories, Engine und Touchpoints. Der Agent ist dabei rein fiktiv und nicht als Objekt vorhanden. Die Funktion eines Agenten kann eine RCP Applikation für sich selber erfüllen, aber es kann auch eine andere unabhängige Applikation sein. Artefact Artefakte sind die Bundle JARs, also die Pakete die installiert werden. Artefacts befinden sich im Artefact Repository. Auch das Installationsverzeichnis einer Eclipse Installation fungiert als Artefact Repository. Die zu Verfügung stehenden Artefacte sind im artefact.xml (bzw artefact.jar) aufgeführt. Bundle Pool Ein Bundlepool ist üblichweise ein Verzeichnis mit Plugins (Bundles). Diese können in verschiedenen Versionen vorliegen. Bei einem Shared Bundle Pool teilen sich mehrere Appliationen diesen Bundle Pool. Director Der Director ist die zentrale Komponente eines Installationsvorganges. Er lässt über den Planner aus den Metadaten die nötigen Systemänderungen (Provisioning Operations) ermitteln und startet dann die Engine um die noch benötigten ermittelten Artefakte aus den remoten Repositories herunter zuladen und die Änderungen im Profil der RCP Anwendung auszuführen. siehe » Director Application Dropins-Verzeichnis Mit der Einführung von p2 dient das Pluginverzeichnis einer Eclipseinstallation automatisch als Bundlep Pool und damit auch als Artefact Repository. War es früher üblich Plugins durch das einfache Kopieren in das Pluginverzeichnis einer Eclipse IDE hinzuzufügen sollte seit Eclipse 3.4 das Dropin-Verzeichnis dazu verwendet werden. Plugins, die in das Dropins-Verzeichnis kopiert werden, werden automatisch in der Eclipse IDE installiert. Unter Eclipse 3.5.1 gilt dies jedoch auch noch für die Plugin-Verzeichnis. Engine Die Engine führt die durch den Director aus den Metadaten als nötig ermittelten Änderungen an der Installation der RCP Applikation aus. Zum Beispiel werden nicht mehr benötigte Bundels aus dem Profil (aber nicht aus dem Bundle Pool!) entfernt. Noch nicht vorhandene Artefakte werden aus dem Repository in den Bundle Pool der RCP Applikation geladen. Änderungen von Programm und JVM Argumente werden in den entsprechenden Konfigurationdateien (eclipse.ini, launcher.ini) gesetzt. Der Ausführungsprozess der Engine ist dabei in mehrere Phasen unterteilt, so dass die einzelnen Aktionen koordiniert ausgeführt werden können. Als Default Phasen gibt es collect, unconfigure, uninstall, property, check trust, install, configure. Die Ausführung der Systemänderung wird an eine zuständige Touchpoint Action delegiert. Metadata - Installable Units(IU) Die Metadaten befinden sich in einem Metadaten Repository und bestehen im Grunde aus einer xml Datei in welcher alle installierbaren Einheiten, die so genannten Installabel Units (IU), mit ihren Abhängigkeiten zueinander aufgelistet sind. Eine Installable Unit kann zum Beispiel ein Bundle (Plugin) oder auch ein zusammenfassendes Feature beschreiben. Gekennzeichnet ist eine IU analog zu Bundles durch eine id und einer Versionsnummer, die global eindeutig sein muss. Die Beschreibung enthält den Namen, Version, die bereit gestellten und die benötigten Capabilities (Provides and Required Capabilities), sowie Touchpoint-Anweisungen. Die Trennung von Metadaten und Artefakten ermöglicht es, die Ermittlung von Abhängigkeiten unabhängig von den Artefakten durchzuführen. Ein Artefakt muss also nicht lokal vorhanden sein um aus den Metadaten zuermitteln welche anderen Artefakte es benötigt. Soll ein Product installiert werden, so ist dessen IU Ausgangsbasis für die Ermittlung aller Abhängigkeiten. Aufgeführt sind zum Beispiel alle IUs welche die benötigten Features beschreiben, die wiederum haben Abhängigkeiten zu einer Reihe von Plugins. Planner Der Planner ist zuständig für die Ermittlung welche Provisioning-Operationen duchgeführt werden müssen um eine Applikation so zu verändern, damit sie dem neuen gewünschten Zustand entspricht. Ausgangsbasis für die Ermittlung ist das aktuelle Profil welches den Ist-Zustand beschreibt. Bei einer Neuinstallation ist das Profil leer bzw nicht vorhanden. Der Applikation sollen nun IUs hinzugefügt und/oder entfernt werden. Das Profil soll sich also in diese Richtung verändern. Anhand der Metadaten ermittelt der Plannern nun welche Provisioning-Operationen durchgeführt werden müssen. Profile Der Istzustand einer RCP Applikation wird durch ein Profil in der Profil Registry beschrieben. Das Profil enthält die Metadaten aller installierten IUs welche die Applikation ausmachen. Damit ist es möglich zu ermitteln welche IUs zu der durch das Profil repräsentierten RCP Applikation gehören und welche Provisioning-Operationen bei einer Entfernung aus der Applikation ausgeführt werden müssen. Teilen sich mehrere Applikation ein Bundle Pool muss jede ein eigenes Profil besitzen. Eine IU eines Artefakts aus dem Bundle Pool kann in einem oder mehreren Profilen aus der Profil Registry vorkommen oder aber wenn es deinstalliert wurde in keinem. Touchpoint Die Installation einer Software ist abhängig von seiner Umgebung. Das Interface zwischen der Engine und dem Zielsystem bilden die Touchpoints. Ein Touchpoint ermöglicht die Ausführung einer Provisioning-Operation auf dem Zielsystem. Der Eclipse Touchpoint übernimmt die Aufgabe die Bundles in die Equinox Platform zu integrieren. Für unterschiedlichen Betriebssysteme gibt es zudem Native Touchpoints, die zum Beispiel das Entzippen von Dateien oder die Rechtevergabe von Verzeichnissen ermöglichen falls das Betriebssystem ies unterstützt.

	07.08.2011, Silke Schlüter, Impressum