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 las especificaciones de OSGi.
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.
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 puede utilizarse en una cabecera Export-Package para especificar si el paquete es interno. El entorno de desarrollo de plug-ins (PDE) 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 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 plug-ins (PDE) 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.eclipse.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 plug-ins desalentará que otros paquetes utilicen ese paquete aunque se hayan especificado como amigos.
La cabecera Eclipse-LazyStart se utiliza para especificar si un paquete compuesto debe iniciarse automáticamente antes de que se acceda a la primera clase o recurso desde ese paquete compuesto. Esta característica permite que Eclipse active paquetes compuestos de forma diferida 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-LazyStart debe utilizar la sintaxis siguiente:
Eclipse-LazyStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ? exceptions-list ::= un lista de paquetes separados por comas ','
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-LazyStart no está definida en el manifiesto de paquete compuesto, se utiliza el valor predeterminado 'false'. A continuación figura un ejemplo de la cabecera Eclipse-LazyStart:
Eclipse-LazyStart: 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-AutoStart ha quedado obsoleta en Eclipse 3.2. En su lugar, debe utilizarse la cabecera Eclipse-LazyStart.
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 ::= una serie de filtro LDAP válida
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 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 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 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 Eclipse-GenericCapability se utiliza para especificar una prestación genérica de un paquete compuesto. Las prestaciones genéricas pueden utilizarse para describir características del paquete compuesto que otros paquetes compuestos del sistema pueden necesitar (utilizando la cabecera Eclipse-GenericRequire). Las prestaciones genéricas reciben un nombre y un tipo de prestación. Los tipos de prestaciones se definen en el paquete que ofrece la prestación. Las prestaciones también pueden tener un conjunto de atributos coincidentes con tipo que se utilizan para la comparación al resolver cabeceras Eclipse-GenericRequire. Los atributos coincidentes pueden ser de uno de los tipos siguientes: [string | version | uri | long | double | set]. El tipo de conjunto puede utilizarse para definir un conjunto de series en forma de lista de series separadas por comas. La cabecera Eclipse-GenericCapability debe utilizar la sintaxis siguiente:
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] )
A continuación figura un ejemplo de la cabecera Eclipse-GenericCapabilty que puede utilizarse para especificar un paquete compuesto con una implementación de org.acme.stuff.SomeService de servicio OSGi:
Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service; version:version="1.0.1"
La cabecera Eclipse-GenericRequire se utiliza para especificar un requisito sobre una prestación genérica ofrecida por otro paquete compuesto (utilizando la cabecera Eclipse-GenericCapability). Los requisitos genéricos reciben un nombre y un tipo de prestación. Los tipos de prestaciones se definen en el paquete que ofrece la prestación. Los requisitos genéricos pueden especificar una serie de filtro LDAP que se utiliza como filtro de selección para la resolución de prestaciones genéricas coincidentes. La cabecera Eclipse-GenericRequire debe utilizar la sintaxis siguiente:
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 )
A continuación figura un ejemplo de la cabecera Eclipse-GenericRequire que puede utilizarse para especificar un paquete compuesto que depende de una implementación de org.acme.stuff.SomeService de servicio OSGi:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service; selection-filter="(version>=1.0.1)"
La opción osgi.genericAliases puede utilizarse para correlacionar cabeceras de manifiesto OSGi existentes con cabeceras de manifiesto Eclipse-GenericCapability y Eclipse-GenericRequire. Por ejemplo, considere las siguientes cabeceras de manifiesto:
Export-Service: org.acme.stuff.SomeService Import-Service: org.acme.stuff.SomeService
Estas cabeceras pueden correlacionarse con cabeceras Eclipse-GenericCapability y Eclipse-GenericRequire utilizando la siguiente propiedad:
osgi.genericAliases=Export-Service:Import-Service:osgi.service
Internamente, esto se traducirá en las siguientes cabeceras genéricas:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service
La cabecera Plugin-Class sólo se utiliza para dar soporte a los plug-ins desarrollados por la plataforma Eclipse 2.1. Esta cabecera se utiliza para especificar un nombre de clase que se utilizará para activar un plug-in utilizando el antiguo modelo de activación de Eclipse 2.1. Los nuevos paquetes compuestos desarrollados para 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