Cabeceras de manifiesto de paquete SGi

Versión 3.1 - Última revisión: 20 de junio de 2005

Un paquete puede transportar información descriptiva sobre sí mismo en el archivo de manifiesto denominado META-INF/MANIFEST.MF. La especificación OSGi R4 Framework define un conjunto de cabeceras de manifiesto como Export-Package y Bundle-Classpath, que los desarrolladores de paquetes utilizan para proporcionar información descriptiva sobre un paquete. Eclipse OSGi Framework implementa la especificación OSGi R4 Framework completa y todos los servicios Core Framework. Los servicios OSGi R4 Core Framework son, entre otros, los siguientes:

Hay varios servicios opcionales definidos en la especificación OSGi R4. Los servicios opcionales no están incluidos con la implementación de Eclipse OSGi Framework. Para obtener información sobre las cabeceras y servicios de manifiesto de OSGi R4, consulte la Especificaciones OSGi.

Cabeceras de manifiesto de paquete Eclipse

Eclipse OSGi Framework da soporte a varias cabeceras y directivas de manifiesto de paquetes adicionales. Un desarrollador de paquetes puede utilizar estas cabeceras y directivas adicionales para aprovechar algunas características adicionales de Eclipse OSGi Framework que no se especifican como parte de un infraestructura OSGi R4 estándar.

Directivas Export-Package adicionales

Eclipse OSGi Framework da soporte a directivas adicionales en la cabecera Export-Package. Estas directivas se utilizan para especificar las reglas de restricción de acceso de un paquete exportado. Consulte osgi.resolverMode para configurar Eclipse OSGi Framework con el fin de aplicar las reglas de restricción de acceso en el entorno de ejecución.

La directiva x-internal

La directiva x-internal puede utilizarse en una cabecera Export-Package para especificar si el paquete es interno. El Entorno de desarrollo de conectores desalentará que otros paquetes utilicen un paquete interno. Si no se especifica la directiva x-internal, se utiliza el valor por omisión 'false'. La directiva x-internal debe utilizar la sintaxis siguiente:

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

El siguiente es un ejemplo de la directiva x-internal:

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

La directiva x-friends

La directiva x-friends puede utilizarse en una cabecera Export-Package para especificar una lista de paquetes a los que se permitirá el acceso al paquete. El Entorno de desarrollo de conectores desalentará que otros paquetes utilicen el paquete. La directiva x-friends debe utilizar la sintaxis siguiente:

x-friends ::= '"' ( target-bundle ) ( ',' target-bundle ) * '"'
target-bundle ::= a bundle symbolic name

El siguiente es un ejemplo de la directiva x-friends:

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

El ejemplo especifica que sólo los paquetes org.eclipse.foo.friend1 y org.eclipse.foo.friend2 deben ser alentados para utilizar el paquete org.eclipse.foo.formyfriends. El paquete x-internal tiene prioridad sobre la directiva x-friends. Si la directiva x-internal especifica 'true', el Entorno de desarrollo de conectores desalentará que otros paquetes utilicen ese paquete aunque se hayan especificado como amigos.

La cabecera Eclipse-AutoStart

La cabecera Eclipse-AutoStart se utiliza para especificar si un paquete debe iniciarse automáticamente antes de que se acceda a la primera clase o recurso desde ese paquete. Esta característica permite que Eclipse active paquetes bajo demanda la primera vez que los necesite. Al utilizar este modelo, Eclipse puede arrancarse con el menor número posible de paquetes activos. La cabecera Eclipse-AutoStart debe utilizar la sintaxis siguiente:

Eclipse-AutoStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ?
exceptions-list ::= a comma ',' separated list of packages

El atributo 'exceptions' se utiliza para especificar una lista de paquetes que no deben causar que se active el paquete cuando se carguen clases o recursos desde ellos. Si la cabecera Eclipse-AutoStart no está definida en el manifiesto de paquete se utiliza el valor por omisión 'false'. El siguiente es un ejemplo de la cabecera Eclipse-AutoStart:

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

El ejemplo especifica que este paquete debe activarse para las clases o recursos que se carguen desde este paquete, excepto las clases y recursos de los paquetes 'org.eclipse.foo1' y 'org.eclipse.foo2'.

La cabecera Eclipse-PlatformFilter

Eclipse-PlatformFilter se utiliza para especificar un filtro de plataforma para un paquete. Un filtro de plataforma debe evaluarse como true en una plataforma en ejecución para que se permita que se resuelva un paquete. La cabecera Eclipse-PlatformFilter debe utilizar la siguiente sintaxis:

Eclipse-PlatformFilter ::= a valid LDAP filter string

Framework da soporte al filtrado en las siguientes propiedades del sistema:

El siguiente es un ejemplo de la cabecera Eclipse-PlatformFilter:

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

Este ejemplo especifica que este paquete sólo puede resolverse i las propiedades de plataforma son osgi.ws=win32, osgi.os=win32 y osgi.arch=x86. En otras palabras, una plataforma se ejecuta en una arquitectura x86, utilizando un sistema operativo win32 y el sistema de ventanas win32.

La cabecera Eclipse-BuddyPolicy

La cabecera Eclipse-BuddyPolicy se utiliza para especificar las políticas de carga de clase amiga para un paquete. La cabecera Eclipse-BuddyPolicy debe utilizar la sintaxis siguiente:

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

El siguiente es un ejemplo de la cabecera Eclipse-BuddyPolicy:

Eclipse-BuddyPolicy: dependent

La cabecera Eclipse-RegisterBuddy

La cabecera Eclipse-RegisterBuddy se utiliza para especificar una lista de paquete para los que este paquete es un amigo registrado. La cabecera Eclipse-RegisterBuddy debe utilizar la sintaxis siguiente:

Eclipse-RegisterBuddy ::= ( target-bundle ) ( ',' target-bundle ) *
target-bundle ::= a bundle symbolic name

El siguiente es un ejemplo de la cabecera Eclipse-RegisterBuddy:

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

La cabecera Eclipse-ExtensibleAPI

La cabecera Eclipse-ExtensibleAPI se utiliza para especificar si un paquete de host permite que paquetes de fragmentos añadan una API adicional al host. Esta cabecera debe utilizarse si un paquete de host quiere permitir que los fragmentos añadan paquetes adicionales a la API del host. Si no se especifica esta cabecera, se utiliza el valor por omisión 'false'. La cabecera Eclipse-ExtensibleAPI debe utilizar la sintaxis siguiente:

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

El siguiente es un ejemplo de la cabecera Eclipse-ExtensibleAPI:

Eclipse-ExtensibleAPI: true

La cabecera Plugin-Class

La cabecera Plugin-Class sólo se utiliza para dar soporte a los conectores desarrollados por la plataforma Eclipse 2.1. Esta cabecera se utiliza para especificar un nombre de clase que se utilizará para activar un conector utilizando el antiguo modelo de activación de Eclipse 2.1. Los nuevos paquetes desarrollados para la plataforma Eclipse 3.0 o superior no deben utilizar esta cabecera. El siguiente es un ejemplo de la cabecera Plugin-Class:

Plugin-Class: org.eclipse.foo.FooPlugin