The Eclipse framework, and therefore the client platform, is organized around a plug-in and extension point model. The framework provides a core set of components. Additional components are provided in a directory or JAR file organized in a specific structure, and implement instantiations of the various extension points. The framework reads the component declarative information, and incorporates the components into the correct locations in the framework.
is the level at which components are declared to the Eclipse framework. A plug-in is a JAR file with a plug-in manifest file named plugin.xml
. The plug-in manifest describes the plug-in to the framework and enables a plug-in to consume and/or provide extensions from/to other plug-ins. For example, a plug-in can provide user interface extensions, such as perspectives, views, editors, and wizards. It can also provide business logic or core services to other plug-ins, but contribute no extensions to the user interface.
is the level at which components are declared to the OSGi Service Framework. A bundle is a JAR file with a bundle manifest file named MANIFEST.MF
. The bundle manifest describes the bundle to the service framework and enables a bundle to consume and/or provide packages and services from/to other bundles. Bundles can also include a Bundle Activator class. The Bundle-Activator header in the bundle manifest file identifies the class to the framework. At startup time, the framework creates an instance of this class and calls its start()
method. The Bundle Activator can then publish services, start its own threads, and so on. When the bundle shuts down, the framework calls the activator's stop()
method. While the bundle shuts down, the Bundle Activator can release resources that are obtained since the start method was called and revoke any services it has published.
Recall that the Eclipse framework is built on the OSGi Service Framework. Therefore, you can define each component in your applications as a plug-in, a bundle, or both depending on your requirements.
For a component to be recognized by the client platform, the toolkit and the Eclipse Plug-in Development Environment (PDE), it must have a unique name and version. If you develop a plug-in, specify a unique value for the name
attribute and a version number for the version
attribute in the plug-in manifest. If you develop a bundle, specify a unique value for the Bundle-SymbolicName
attribute and a version number for the Bundle-Version
attribute in the bundle manifest.
A component can generally be organized in one of three ways:
- A directory containing at least a plugin.xml file. The directory may also contain a MANIFEST.MF file located in the META-INF directory, additional files, as well as Java code contained within JAR files.
A plugin.xml file is required if the component defines extension points for use by other plug-ins or implements extension points provided by other plug-ins.
- A directory containing at least a MANIFEST.MF file in the META-INF directory. The directory will also contain Java code contained in JAR files. The MANIFEST.MF will refer to the JARs by referencing them via the Bundle-Classpath attribute.
Components that provide only business logic or OSGi services and do not intend to provide or implement any extension points can use this format. Components without plugin.xml files that need to be available when building other components or when launching the client platform by using either the toolkit or the PDE must be organized in this format.
- A single JAR file containing at least a META-INF\\MANIFEST.MF or a plugin.xml file.
Components may be provided for use in the client platform by collecting all of the component artifacts into a single JAR file. While this organization will run successfully, this organization is not compatible with the toolkit and Eclipse PDE.
Parent topic: Packaging: XPD622