Version 3.3 - Last revised April 27, 2011
A bundle can carry descriptive information about itself in the manifest file named META-INF/MANIFEST.MF. The OSGi R7 Framework specification defines a set of manifest headers such as Export-Package and Bundle-Classpath, which bundle developers use to supply descriptive information about a bundle. The Equinox OSGi Framework implements the complete OSGi R7 Framework specification and all of the Core Framework services. The OSGi R7 Core Framework services include the following:
There are a number of optional services defined in the OSGi R7 compendium specification. The optional services are not included with the Equinox OSGi Framework implementation. For information on OSGi R7 manifest headers and services refer to the OSGi specifications.
The Eclipse OSGi Framework supports a number of additional bundle manifest headers and directives. A bundle developer may use these additional headers and directives to take advantage of some additional features of the Eclipse OSGi Framework which are not specified as part of a standard OSGi Framework.
The Eclipse OSGi Framework supports additional directives on the Export-Package header. These directives are used to specify the access restriction rules of an exported package. See osgi.resolverMode to configure the Eclipse OSGi Framework to enforce the access restriction rules at runtime.
The x-internal directive can be used in an Export-Package header to specify whether the package is an internal package. The Plug-in Development Environment will discourage other bundles from using an internal package. If the x-internal directive is not specified then a default value of 'false' is used. The x-internal directive must use the following syntax:
x-internal ::= ( 'true' | 'false' )
The following is an example of the x-internal directive:
Export-Package: org.eclipse.foo.internal; x-internal:=true
The x-friends directive can be used in an Export-Package header to specify a list of bundles which are allowed access to the package. The Plug-in Development Environment will discourage other bundles from using the package. The x-friends directive must use the following syntax:
x-friends ::= '"' ( target-bundle ) ( ',' target-bundle ) * '"' target-bundle ::= a bundle symbolic name
The following is an example of the x-friends directive:
Export-Package: org.eclipse.foo.formyfriends; x-friends:="org.eclipse.foo.friend1, org.eclipse.foo.friend2"
The example specifies that only the bundles org.eclipse.foo.friend1 and org.eclipse.foo.friend2 should be encouraged to use the org.eclipse.foo.formyfriends package. The x-internal package takes priority over the x-friends directive. If the x-internal directive specifies 'true' then The Plug-in Development Environment will discourage all bundles from using the package even if they are specified as a friend.
The Eclipse-LazyStart header is used to specify if a bundle should be started before the first class or resource is accessed from that bundle. This feature allows Eclipse to activate bundles lazily the first time they are needed. Using this model Eclipse can startup with as few active bundles as possible. The Eclipse-LazyStart header must use the following syntax:
Eclipse-LazyStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ? exceptions-list ::= a comma ',' separated list of packages
When Eclipse-LazyStart is true, the 'exceptions' attribute specifies a list of packages that will not cause the bundle to be activated when classes are loaded from them. When Eclipse-LazyStart is false, the 'exceptions' attribute specifies a list of packages that will cause the bundle to be activated when classes are loaded from them. The exception rules apply to all classes in the listed packages. When a bundle is activated the bundle's BundleActivator.start(BundleContext) method will be called.
If the Eclipse-LazyStart header is not defined in the bundle manifest then a default value of 'false' is used. The following is an example of the Eclipse-LazyStart header:
Eclipse-LazyStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"
The example specifies that this bundle must be activated for any classes that are loaded from this bundle, except the classes in the packages 'org.eclipse.foo1' and 'org.eclipse.foo2'.
The Eclipse-AutoStart and Eclipse-LazyStart headers have been deprecated in Eclipse 3.4. As of the OSGi R4.1 specification the lazy activation policy has been adopted by the OSGi specification. The new OSGi bundle manifest header Bundle-ActivationPolicy can be used to specify a lazy activation policy.
The Equinox Framework version 3.4 or later will continue to support the deprecated Eclipse-LazyStart and Eclipse-AutoStart headers. Bundle developers that want their bundles to work across other OSGi Framework implementations should add the Bundle-ActivationPolicy header to their manifest. In most cases you can simply add the following header:
Bundle-ActivationPolicy: lazy
If the 'exceptions' attribute is used with the Eclipse-LazyStart or Eclipse-AutoStart header then the 'include' or 'exclude' directive can be used with the Bundle-ActivationPolicy header. Consider the following Eclipse-LazyStart header:
Eclipse-LazyStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"
The equivalent Bundle-ActivationPolicy header would be the following:
Bundle-ActivationPolicy: lazy; exclude:="org.eclipse.foo1, org.eclipse.foo2"
The following is an example Eclipse-LazyStart header that uses a false value with the exceptions attribute:
Eclipse-LazyStart: false; exceptions="org.eclipse.foo1, org.eclipse.foo2"
The equivalent Bundle-ActivationPolicy header would be the following:
Bundle-ActivationPolicy: lazy; include:="org.eclipse.foo1, org.eclipse.foo2"
The Eclipse-PlatformFilter is used to specify a platform filter for a bundle. A platform filter must evaluate to true in a running platform in order for a bundle to be allowed to resolve. The Eclipse-PlatformFilter header must use the following syntax:
Eclipse-PlatformFilter ::= a valid LDAP filter string
The Framework supports filtering on the following system properties:
The following is an example of the Eclipse-PlatformFilter header:
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
This example specifies that this bundle can only be resolved if the platform properties are osgi.ws=win32 and osgi.os=win32 and osgi.arch=x86. In other words a platform running on an x86 architecture, using a win32 operating system and the win32 windowing system.
The Eclipse-BuddyPolicy header is used to specify the buddy classloading policies for a bundle. The Eclipse-BuddyPolicy header must use the following syntax:
Eclipse-BuddyPolicy ::= ( policy-name ) ( ',' policy-name ) *
policy-name ::= ( 'dependent' | 'global' | 'registered' |
'app' | 'ext' | 'boot' | 'parent' )
The following is an example of the Eclipse-BuddyPolicy header:
Eclipse-BuddyPolicy: dependent
The Eclipse-RegisterBuddy header is used to declare a comma-separated list of symbolic names of bundles that this bundle should be a registered buddy to. The bundles with the specified symbolic names must use the registered buddy policy (specified by the Eclipse-BuddyPolicy) header) in order for this bundle to be a registered buddy.
Note that the following conditions must be met before a bundle X can become a registered buddy of another bundle Y:
The syntax of the Eclipse-RegisterBuddy header is the following:
Eclipse-RegisterBuddy ::= ( target-bundle ) ( ',' target-bundle ) * target-bundle ::= a bundle symbolic name
The following is an example of the Eclipse-RegisterBuddy header:
Eclipse-RegisterBuddy: org.eclipse.foo.bundle1, org.eclipse.foo.bundle2
The Eclipse-ExtensibleAPI is used to specify whether a host bundle allows fragment bundles to add additional API to the host. This header should be used if a host bundle wants to allow fragments to add additional packages to the API of the host. If this header is not specified then a default value of 'false' is used. Note that this header is only used by tooling (PDE) to construct proper class paths for building. The runtime does not use this header at all. At runtime a fragment is always allowed to add additional packages, classes and resources to the API of the host. The Eclipse-ExtensibleAPI header must use the following syntax:
Eclipse-ExtensibleAPI ::= ( 'true' | 'false' )
The following is an example of the Eclipse-ExtensibleAPI header:
Eclipse-ExtensibleAPI: true
The Eclipse-BundleShape header is used to specify the deployment shape a bundle should use when the bundle is provisioned to an Eclipse installation. The runtime does not use this header at all. This header is only used by the build and provisioning systems to determine how to deploy a bundle. The Eclipse-BundleShape header must use the following syntax:
Eclipse-BundleShape ::= ( 'jar' | 'dir' )
The "jar" value indicates that the bundle should be deployed as a jar. The "dir" value indicates that the bundle should be unpacked into a directory when deployed to an Eclipse installation.
If a product uses PDE to build a feature based product then, if specified, the value of the unpack attribute in the feature.xml file takes precedence over the Eclipse-BundleShape header.
The following is an example of the Eclipse-BundleShape header:
Eclipse-BundleShape: jar
Note: the Eclipse-GenericCapability header has been deprecated. The OSGi R4.3 Core Framework specification includes a new header Provide-Capability which can be used to specify generic capabilities provided by a bundle. Equinox will continue to support both the Eclipse-GenericCapability header and the new OSGi Provide-Capability header.
The Eclipse-GenericCapability header is used to specify a generic capability of a bundle. Generic capabilities can be used to describe features of your bundle which can be required by other bundles in the system (using the Eclipse-GenericRequire header). Generic capabilities are given a name and a capability type. Capability types are defined by the bundle which is offering the capability. Capabilities can also have a set of typed matching attributes which are used to match against when resolving Eclipse-GenericRequire headers. Matching attributes may be one of the following types; [string | version | uri | long | double | set]. The set type can be used to define a set of strings as a comma separated list of strings. The Eclipse-GenericCapability header must use the following syntax:
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] )
The following is an example of the Eclipse-GenericCapability header that could be used to specify a bundle with an OSGi service org.acme.stuff.SomeService implementation:
Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service; version:version="1.0.1"
Note: the Eclipse-GenericRequire header has been deprecated. The OSGi R4.3 Core Framework specification includes a new header Require-Capability which can be used to specify a requirement on a generic capabilities provided by another bundle. Equinox will continue to support both the Eclipse-GenericRequire header and the new OSGi Require-Capability header.
The Eclipse-GenericRequire header is used to specify a requirement on a generic capability which is offered by another bundle (using the Eclipse-GenericCapability header). Generic requirements are given a name and a capability type. Capability types are defined by the bundle which is offering the capability. Generic requirements can specify an LDAP filter string which is used as a selection filter to resolve against matching generic capabilities. The Eclipse-GenericRequire header must use the following syntax:
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 )
The following is an example of the Eclipse-GenericRequire header that could be used to specify a bundle that depends on an OSGi service org.acme.stuff.SomeService implementation:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service; selection-filter="(version>=1.0.1)"
The osgi.genericAliases option can be used to map existing OSGi manifest headers onto Eclipse-GenericCapability and Eclipse-GenericRequire manifest headers. For example, consider the following manifest headers
Export-Service: org.acme.stuff.SomeService Import-Service: org.acme.stuff.SomeService
These headers can be mapped to Eclipse-GenericCapability and Eclipse-GenericRequire headers using the following property:
osgi.genericAliases=Export-Service:Import-Service:osgi.service
Under the covers this would translate into the following generic headers:
Eclipse-GenericRequire: org.acme.stuff.SomeService:osgi.service Eclipse-GenericCapability: org.acme.stuff.SomeService:osgi.service
The Plugin-Class header is only used to support plugins developed for the Eclipse 2.1 platform. This header is used to specify a class name that will be used to activate a plug-in using the old Eclipse 2.1 activation model. New bundles developed for Eclipse 3.0 or greater should not use this header. The following is an example of the Plugin-Class header:
Plugin-Class: org.eclipse.foo.FooPlugin
The Model-Fragment header is used to register a model fragment file as an extension to the application model, similarly to extensions of org.eclipse.e4.workbench.model. The EModel-Fragment header must use the following syntax:
Model-Fragment ::= filename;apply= ( 'always' | 'initial' | 'notexists' )The following is an example of the Model-Fragment header:
Model-Fragment: fragment.e4xmi;apply=always
The apply attribute is optional and defaults to always. It can have the following values: