OSGi-Produktpaketmanifestheader

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 unter OSGi-Spezifikation.

Eclipse-Produktpaketmanifestheader

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.

Zusätzliche Steueranweisungen für 'Export-Package

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'

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'

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.eclispe.foo.friend1, org.eclipse.foo.friend2"

Das Beispiel gibt an, dass nur die Produktpakete 'org.eclispe.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-AutoStart'

Der Header 'Eclipse-AutoStart' 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 bedarfsgerecht aktivieren, wenn sie zum das erste Mal benötigt werden. Über dieses modellieren kann Eclipse mit möglichst wenig aktiven Produktpaketen gestartet werden. Der Header 'Eclipse-AutoStart' muss die folgende Syntax haben:

Eclipse-AutoStart ::= ( '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-AutoStart' im Produktpaketmanifest nicht definiert ist, so wird als Standardwert 'false' verwendet. Die folgenden Angaben sind ein Beispiel für den Header 'Eclipse-AutoStart':

Eclipse-AutoStart: 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-PlatformFilter'

'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'

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'

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

Der Header 'Eclipse-ExtensibleAPI'

'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 'Plugin-Class'

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 Eclipse 2.1 Aktivierungsmodell zu aktivieren. Neue Produktpakete, die für die Plattform 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