En-têtes du manifeste du bundle OSGi

Version 3.1 - Dernière révision : 30 juin 2005

Un bundle peut disposer d'informations descriptives le concernant dans le fichier de manifeste appelé META-INF/MANIFEST.MF. La spécification de la plate-forme OSGi R4 définit un ensemble d'en-têtes de manifeste (Export-Package et Bundle-Classpath par exemple) que les développeurs peuvent utiliser pour fournir des informations descriptives sur un bundle. La plate-forme OSGi Eclipse implémente la spécification de la plate-forme R4 ainsi que tous les services de base. Les services de base de la plate-forme OSGi R4 comprennent :

Il existe un certain nombre de services facultatifs définis dans les spécifications OSGi R4. Ces services facultatifs ne sont pas inclus dans l'implémentation de la plate-forme OSGi Eclipse. Pour obtenir des informations supplémentaires sur les services et les en-têtes du manifeste OSGi R4, consultez les spécifications OSGi R4.

En-têtes du manifeste du bundle Eclipse

La plate-forme Eclipse OSGi prend en charge un grand nombre d'en-têtes et d'instructions supplémentaires pour le manifeste du bundle. Un développeur peut utiliser ces en-têtes et instructions supplémentaires pour bénéficier de fonctionnalités de la plate-forme OSGi Eclipse ne faisant pas partie de la plate-forme OSGi classique.

Instructions Export-Package supplémentaires

La plate-forme OSGi Eclipse prend en charge des instructions supplémentaire de l'en-tête Export-Package. Ces instructions permettent d'indiquer les règles de restriction d'accès d'un module exporté. Consultez osgi.resolverMode pour configurer la plate-forme OSGi Eclipse afin d'appliquer les règles de restriction d'accès lors de l'exécution.

Instruction x-internal

L'instruction x-internal peut être utilisée dans un en-tête Export-Package pour indiquer qu'un module est un module interne. L'environnement de développement du plug-in limite l'intérêt de l'utilisation d'un module interne par les autres bundles. Si l'instruction x-internal n'est pas spécifiée, la valeur par défaut 'false' est utilisée. L'instruction x-internal doit utiliser la syntaxe suivante :

x-internal ::= ( 'true' | 'false' )

Voici un exemple d'instruction x-internal :

Export-Package: org.eclipse.foo.internal; x-internal:=true

Instruction x-friends

L'instruction x-friends peut être utilisée dans un en-tête Export-Package pour spécifier une liste de bundles autorisés à accéder au module. L'environnement de développement du plug-in limite l'intérêt de l'utilisation d'un module interne par les autres bundles. L'instruction x-friends doit utiliser la syntaxe suivante :

x-friends ::= '"' ( target-bundle ) ( ',' target-bundle ) * '"'
target-bundle ::= nom de bundle symbolique

Voici un exemple d'instruction x-friends :

Export-Package: org.eclipse.foo.formyfriends; x-friends:="org.eclispe.foo.friend1, org.eclipse.foo.friend2"

Cette exemple indique que seuls les bundles org.eclispe.foo.friend1 et org.eclipse.foo.friend2 doivent être incités à utiliser le module org.eclipse.foo.formyfriends. Le module x-internal est prioritaire par rapport à l'instruction x-friends. Si l'instruction x-internal indique 'true', l'environnement de développement du plug-in n'incitera pas les bundles à utiliser le module même s'ils ont la mention friend (ami).

En-tête Eclipse-AutoStart

L'en-tête Eclipse-AutoStart permet d'indiquer qu'un bundle doit être démarré automatiquement avant de pouvoir accéder à la première classe ou ressource de ce bundle. Cette fonctionnalité permet à Eclipse d'activer des bundles à la demande dès qu'ils sont nécessaire pour la première fois. Grâce à ce modèle, Eclipse peut démarrer avec le moins de bundles actifs que possible. L'en-tête Eclipse-AutoStart doit utiliser la syntaxe suivante :

Eclipse-AutoStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ?
exceptions-list ::= liste de modules séparés par une virgule ','

L'attribut 'exceptions' permet d'indiquer la liste des modules n'activant pas les bundles lorsqu'ils chargent des classes ou des ressources de ces derniers. Si l'en-tête Eclipse-AutoStart n'est pas défini dans le manifeste du bundle, la valeur par défaut 'false' est utilisée. Voici un exemple d'en-tête Eclipse-AutoStart :

Eclipse-AutoStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"

L'exemple suivant indique que ce bundle doit être activé à chaque chargement de l'une de ses classes ou ressources, à l'exception des classes et ressources des modules 'org.eclipse.foo1' et 'org.eclipse.foo2'.

En-tête Eclipse-PlatformFilter

L'en-tête Eclipse-PlatformFilter permet de spécifier un filtre de plate-forme pour un bundle. Le filtre d'une plate-forme en cours d'exécution doit avoir la valeur 'true' pour permettre la résolution d'un bundle. L'en-tête Eclipse-PlatformFilter doit utiliser la syntaxe suivante :

Eclipse-PlatformFilter ::= chaîne de filtre LDAP valide

La plate-forme prend en charge les filtres pour les propriétés système suivantes :

Voici un exemple d'en-tête Eclipse-PlatformFilter :

Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))

Cet exemple indique que ce bundle ne peut être résolu que les propriétés de la plate-forme sont les suivantes : osgi.ws=win32, osgi.os=win32 et osgi.arch=x86. En d'autres termes, il s'agit d'une plate-forme avec une architecture x86, un système d'exploitation win32 et un système multifenêtre win32.

En-tête Eclipse-BuddyPolicy

L'en-tête Eclipse-BuddyPolicy permet d'indiquer les règles de chargement des classes amies d'un bundle. L'en-tête Eclipse-BuddyPolicy doit utiliser la syntaxe suivante :

Eclipse-BuddyPolicy ::= ( policy-name ) ( ',' policy-name ) *
policy-name ::= ( 'dependent' | 'global' | 'registered' | 
                  'app' | 'ext' | 'boot' | 'parent' )

Voici un exemple d'en-tête Eclipse-BuddyPolicy :

Eclipse-BuddyPolicy: dependent

En-tête Eclipse-RegisterBuddy

L'en-tête Eclipse-RegisterBuddy permet d'indiquer la liste des bundles pour lesquels le bundle est considéré comme 'ami'. L'en-tête Eclipse-RegisterBuddy doit utiliser la syntaxe suivante :

Eclipse-RegisterBuddy ::= ( target-bundle ) ( ',' target-bundle ) *
target-bundle ::= nom de bundle symbolique

Voici un exemple d'en-tête Eclipse-RegisterBuddy :

Eclipse-RegisterBuddy: org.eclipse.foo.bundle1, org.eclipse.foo.bundle2

En-tête Eclipse-ExtensibleAPI

L'en-tête Eclipse-ExtensibleAPI permet d'indiquer si un bundle hôte autorise les bundles fragments à ajouter des API à l'hôte. Vous devez utiliser cet en-tête pour qu'un bundle hôte autorise les bundles fragments à ajouter des modules à l'API de l'hôte. Si cet en-tête n'est pas spécifié, la valeur par défaut 'false' est utilisée. L'en-tête Eclipse-ExtensibleAPI doit utiliser la syntaxe suivante :

Eclipse-ExtensibleAPI ::= ( 'true' | 'false' )

Voici un exemple d'en-tête Eclipse-ExtensibleAPI :

Eclipse-ExtensibleAPI: true

En-tête Plugin-Class

L'en-tête Plugin-Class n'est utilisé que pour la prise en charge des plug-ins développés pour la plate-forme Eclipse 2.1. Cet en-tête permet d'indiquer le nom de classe utilisé pour activer un plug-in utilisant l'ancien modèle d'activation Eclipse 2.1. Les nouveaux bundles développés pour la plate-forme Eclipse 3.0 et les versions ultérieures n'utilisent pas cet en-tête. Voici un exemple d'en-tête Plugin-Class :

Plugin-Class: org.eclipse.foo.FooPlugin