Each bundle must contain a manifest file. The bundle's manifest file contains data that the framework needs to correctly install and activate the bundle. Legacy Eclipse bundles can provide some manifest information in their plugin.xml
files, but META-INF/MANIFEST.MF files are the recommended files for Manifest information.
l may contain similar information, however, a plugin.xml
also contains extensions and extension points.
If a bundle contains only a plugin.xml
, the Eclipse platform will generate a MANIFEST.MF
equivalent when the platform starts. When you specify data in a manifest file, you must use the headers that were defined by the OSGi™ specification. You can use user-defined headers; however, the framework ignores any headers that it does not understand. Refer to the OSGi Service Platform Release 4 specification for more information about the OSGi Manifest file format and syntax.
file is located in the META-INF
directory of your bundle project. The plugin.xml
file, if present, should be under the root directory.
The following headers are defined in the OSGi Service Release 4 specification and by the Eclipse 3.2.x extensions to the OSGi framework.
Use this header to specify the names of any package that you want your bundle to import from the runtime. If you do not specify the package your bundle needs in this header, you may get a NoClassDefFound exception when the bundle loads.
Note: You must also specify the package you want to import (using Import-Package) in the Export-Package header of the bundle that contains the package.
Use this header to specify the name of any package that you want your bundle to export to the runtime. If you do not specify the packages needed by other bundles in this header, the dependent bundles may not resolve.
Use this header to specify the specific bundles that provides packages you use in your bundle. If you do not specify the bundle which provides the packages you need, you may get a NoClassDefFound exception when the bundle loads.
Use this header to specify the fully-qualified name of the BundleActivator class.
A bundle designates a special class to act as a Bundle Activator. The Framework must instantiate this class and invoke the start and stop methods to start or stop the bundle as needed. The bundle's implementation of the BundleActivator Interface enables the bundle to initialize a task, such as registering services, when the bundle starts and to perform clean-up operations when the bundle stops.
The org.eclipse.core.runtime.Plugin class implements the org.osgi.framework.BundleActivator interface. When creating Client Services projects, a subclass of Plugin will be created and will become the BundleActivator for the plug-in.
You may define your own class to implement the org.osgi.framework.BundleActivator interface.
You can specify this header in the Class field on the Overview Page of the Bundle Manifest Editor.
The Bundle-SymbolicName manifest header can be used to identify a bundle. The Bundle Symbolic Name and Bundle Version allow for a bundle to be uniquely identified in the Framework. It does not replace the need for a Bundle-Name manifest header, which provides a human readable name for a bundle.
You can specify this header in the ID field on the Overview Page of the Bundle Manifest Editor.
Refer to the OSGi Service Platform Release 4 for descriptions of other bundle headers, such as the following, which provide bundle description information:
Parent topic: Creating OSGi bundles