Version 3.1 - Letzte Überarbeitung am 20. Juni 2005
Ein Produktpaket kann in der Manifestdatei namens "META-INF/MANIFEST.MF" beschreibende Informationen über sich selbst enthalten. Die OSGi R4-Gerüstspezifikation definiert einen Satz von Manifestheadern, wie z.B. "Export-Package" und "Bundle-Classpath", die Entwickler von Produktpaketen verwenden, um beschreibende Informationen über ein Produktpaket bereitzustellen. Das Eclipse OSGi-Gerüst implementiert die vollständige OSGi R4 Gerüstspezifikation und alle Kerngerüstservices. Bei den OSGi R4-Kerngerüstservices handelt es sich um:
In der OSGi R4-Spezifikation sind mehrere Zusatzleistungen definiert. Die Zusatzleistungen sind in der Implementierung des Eclipse OSGi-Gerüsts nicht enthalten. Weitere Informationen über OSGi R4-Manifestheader und Services finden Sie in den OSGi-Spezifikationen.
Das Eclipse OSGi-Gerüst unterstützt mehrere zusätzliche Manifestheader und Steueranweisungen für Produktpakete. Ein Entwickler von Produktpaketen kann diese zusätzlichen Header und Steueranweisungen verwenden, um von einigen zusätzlichen Features des Eclipse OSGi-Gerüsts zu profitieren, die nicht als Teil des Standard-OSGi-R4-Gerüsts angegeben sind.
Das Eclipse OSGi-Gerüst unterstützt zusätzliche Steueranweisungen für den Header "Export-Package". Diese Steueranweisungen werden verwendet, um Zugriffsbeschränkungsregeln eines exportierten Pakets anzugeben. Unter osgi.resolverMode finden Sie Informationen darüber, wie Sie das Eclipse OSGi-Gerüst so konfigurieren, dass es die Zugriffsbeschränkungsregeln zur Laufzeit umsetzt.
Die Steueranweisung "x-internal" kann in einem Header "Export-Package" verwendet werden, um anzugeben, ob es sich bei diesem Paket um ein internes Paket handelt. Die Plug-in-Entwicklungsumgebung hält andere Produktpakete davon ab, ein internes Paket zu verwenden. Wird die Steueranweisung "x-internal" nicht angegeben, so wird als Standardwert "false" verwendet. Die Steueranweisung "x-internal" muss die folgende Syntax haben:
x-internal ::= ( 'true' | 'false' )
Die folgenden Angaben sind ein Beispiel für die Steueranweisung "x-internal":
Export-Package: org.eclipse.foo.internal; x-internal:=true
Die Steueranweisung "x-friends" kann in einem Header "Export-Package" verwendet werden, um eine Liste von Produktpaketen anzugeben, denen Zugriff auf das Paket gewährt wird. Die Plug-in-Entwicklungsumgebung hält andere Produktpakete davon ab, das Paket zu verwenden. Die Steueranweisung "x-friends" muss die folgende Syntax haben:
x-friends ::= '"' ( target-bundle ) ( ',' target-bundle ) * '"' target-bundle ::= ein symbolischer Produktpaketname
Die folgenden Angaben sind ein Beispiel für die Steueranweisung "x-friends":
Export-Package: org.eclipse.foo.formyfriends; x-friends:="org.eclipse.foo.friend1, org.eclipse.foo.friend2"
Das Beispiel gibt an, dass nur die Produktpakete "org.eclipse.foo.friend1" und "org.eclipse.foo.friend2" das Paket "org.eclipse.foo.formyfriends" verwenden sollten. Das Paket "x-internal" hat Priorität über die Steueranweisung "x-friends". Wenn die Steueranweisung "x-internal" den Wert "true" bestimmt, so hält die Plug-in-Entwicklungsumgebung alle Produktpakete davon ab, das Paket zu verwenden, selbst wenn sie als "friend" angegeben sind.
Der Header "Eclipse-LazyStart" wird verwendet, um anzugeben, ob ein Produktpaket automatisch gestartet werden soll, bevor von diesem Produktpaket aus auf die erste Klasse bzw. Ressource zugegriffen wird. Über diese Funktion kann Eclipse Produktpakete verzögert aktivieren, wenn sie zum ersten Mal benötigt werden. Über dieses Modell kann Eclipse mit möglichst wenig aktiven Produktpaketen gestartet werden. Der Header "Eclipse-LazyStart" muss die folgende Syntax haben:
Eclipse-LazyStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ? exceptions-list ::= eine durch Kommata ',' getrennte Liste von Paketen
Das Attribut "exceptions" wird verwendet, um eine Liste von Paketen anzugeben, die keine Aktivierung des Produktpakets auslösen dürfen, wenn Klassen oder Ressourcen daraus geladen werden. Wenn der Header "Eclipse-LazyStart" im Produktpaketmanifest nicht definiert ist, so wird als Standardwert "false" verwendet. Die folgenden Angaben sind ein Beispiel für den Header "Eclipse-LazyStart":
Eclipse-LazyStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"
Das Beispiel gibt an, dass dieses Produktpaket für alle Klassen oder Ressourcen aktiviert werden muss, die aus diesem Produktpaket heraus geladen werden, mit Ausnahme der Klassen und Ressourcen in den Paketen "org.eclipse.foo1" und "org.eclipse.foo2".
Der Header "Eclipse-AutoStart" ist ab Eclipse 3.2 veraltet. Stattdessen sollte der Header "Eclipse-LazyStart" verwendet werden.
"Eclipse-PlatformFilter" wird verwendet, um einen Plattformfilter für ein Produktpaket anzugeben. Ein Plattformfilter muss den Wert "true" für eine laufende Plattform ausgeben, damit ein Produktpaket aufgelöst werden darf. Der Header "Eclipse-PlatformFilter" muss die folgende Syntax haben:
Eclipse-PlatformFilter ::= eine gültige LDAP-Filterzeichenfolge
Das Gerüst unterstützt Filterung nach den folgenden Systemeigenschaften:
Die folgenden Angaben sind ein Beispiel für den Header "Eclipse-PlatformFilter":
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
Dieses Beispiel gibt an, dass dieses Produktpaket nur aufgelöst werden darf, wenn die Plattformeigenschaften osgi.ws=win32, osgi.os=win32 und osgi.arch=x86 sind. In anderen Worten: eine Plattform, die auf einer x86-Architektur läuft, ein win32-Betriebssystem und das win32-Fenstertechniksystem verwendet.
Der Header "Eclipse-BuddyPolicy" wird verwendet, um die Buddy-Richtlinien für das Laden von Klassen eines Produktpakets anzugeben. Der Header "Eclipse-BuddyPolicy" muss die folgende Syntax haben:
Eclipse-BuddyPolicy ::= ( policy-name ) ( ',' policy-name ) * policy-name ::= ( 'dependent' | 'global' | 'registered' | 'app' | 'ext' | 'boot' | 'parent' )
Die folgenden Angaben sind ein Beispiel für den Header "Eclipse-BuddyPolicy":
Eclipse-BuddyPolicy: dependent
Der Header "Eclipse-RegisterBuddy" wird verwendet, um eine Liste von Produktpaketen anzugeben, für die das Produktpaket ein registrierter "Buddy" ist. Der Header "Eclipse-RegisterBuddy" muss die folgende Syntax haben:
Eclipse-RegisterBuddy ::= ( target-bundle ) ( ',' target-bundle ) * target-bundle ::= ein symbolischer Produktpaketname
Die folgenden Angaben sind ein Beispiel für den Header "Eclipse-RegisterBuddy":
Eclipse-RegisterBuddy: org.eclipse.foo.bundle1, org.eclipse.foo.bundle2
"Eclipse-ExtensibleAPI" wird verwendet, um anzugeben, ob ein Hostproduktpaket es Fragmentproduktpaketen erlaubt, zusätzliche API zum Host hinzuzufügen. Dieser Header sollte verwendet werden, wenn ein Hostproduktpaket es Fragmenten erlauben soll, zusätzliche Pakete zur API des Hosts hinzuzufügen. Wird dieser Header nicht angegeben, so wird als Standardwert "false" verwendet. Der Header "Eclipse-ExtensibleAPI" muss die folgende Syntax haben:
Eclipse-ExtensibleAPI ::= ( 'true' | 'false' )
Die folgenden Angaben sind ein Beispiel für den Header "Eclipse-ExtensibleAPI":
Eclipse-ExtensibleAPI: true
Der Header "Eclipse-GenericCapability" wird verwendet, um eine generische Funktionalität eines Produktpakets anzugeben. Mit den generischen Funktionalitäten können Sie die Features eines Produktpakets beschreiben, die möglicherweise von anderen Produktpaketen im System benötigt werden (mit dem Header "Eclipse-GenericRequire"). Die generischen Funktionalitäten erhalten einen Namen und einen Funktionalitätstyp. Funktionalitätstypen werden durch das Produktpaket definiert, von dem die Funktionalität angeboten wird. Funktionalitäten können auch eine Gruppe von typisierten Übereinstimmungsattributen enthalten, die beim Auflösen von Headern "Eclipse-GenericRequire" abgeglichen werden. Für die Übereinstimmungsattribute kann einer der folgenden Typen verwendet werden: [string | version | uri | long | double | set]. Mit dem Typ "set" kann eine Gruppe aus Zeichenfolgen in Form einer durch Kommata untergliederten Liste von Zeichenfolgen definiert werden. Der Header "Eclipse-GenericCapability" muss die folgende Syntax aufweisen:
Eclipse-GenericCapability ::= capability ( ',' capability ) * capability ::= typed-name ( ';' typed-name ) * ( ';' typed-param ) * typed-name ::= name ( ':' capability-type ) typed-param ::= typed-key '=' quouted-string typed-key ::= name ( ':' [string | version | uri | long | double | set] )
Das folgende Beispiel zeigt einen Header "Eclipse-GenericCapability" der zur Angabe eines Produktpaktes mit der Implementierung eines OSGi-Services "org.acme.stuff.SomeService" verwendet werden könnte:
Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service; version:version="1.0.1"
Mit dem Header "Eclipse-GenericRequire" wird eine generische Funktionalität, die von einem anderen Produktpaket (unter Verwendung des Headers "Eclipse-GenericCapability") bereitgestellt wird, als Voraussetzung angegeben. Die generischen Voraussetzungen erhalten einen Namen und einen Funktionalitätstyp. Funktionalitätstypen werden durch das Produktpaket definiert, von dem die Funktionalität angeboten wird. Generische Voraussetzungen können eine LDAP-Filterzeichenfolge angeben, die beim Abgleich der generischen Funktionalitäten als Auswahlfilter verwendet wird. Der Header "Eclipse-GenericRequire" muss die folgende Syntax aufweisen:
Eclipse-GenericRequire ::= generic-require ( ',' generic-require ) * generic-require ::= typed-name ( ';' typed-name ) * ( ';' selection-filter '=' quoated-ldapFilter ) ( ';' optional '=' [true|false] ) ( ';' multiple '=' [true|false] ) typed-name ::= name ( ':' capability-type )
Das folgende Beispiel zeigt einen Header "Eclipse-GenericRequire", mit dem ein Produktpaket angegeben werden kann, das von der Implementierung eines OSGi-Services "org.acme.stuff.SomeService" abhängig ist:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service; selection-filter="(version>=1.0.1)"
Mit der Option osgi.genericAliases können Sie vorhandene OSGi-Manifestheader und Manifestheader "Eclipse-GenericCapability" und "Eclipse-GenericRequire" einander zuordnen. Beispiel: Die Manifestheader
Export-Service: org.acme.stuff.SomeService Import-Service: org.acme.stuff.SomeService
können mit der folgenden Eigenschaft zu den Headern "Eclipse-GenericCapability" und "Eclipse-GenericRequire" zugeordnet werden:
osgi.genericAliases=Export-Service:Import-Service:osgi.service
Dies würde intern eine Umsetzung in die folgenden generischen Header bewirken:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service
Der Header "Plugin-Class" wird nur verwendet, um Plug-ins zu unterstützen, die für die Plattform Eclipse 2.1 entwickelt wurden. Dieser Header wird verwendet, um einen Klassennamen anzugeben, der verwendet werden soll, um ein Plug-in mit dem alten Aktivierungsmodelle von Eclipse 2.1 zu aktivieren. Neue Produktpakete, die für Eclipse 3.0 oder höher entwickelt wurden, sollten diesen Header nicht verwenden. Die folgenden Angaben sind ein Beispiel für den Header "Plugin-Class":
Plugin-Class: org.eclipse.foo.FooPlugin