2.4 OSGi Framework
The Eclipse plug-in component model is based on an implementation of the OSGi framework R4.0 specification (http://osgi.org). You can see it at the bottom of Figure 2–4. In a nutshell, the OSGi specification forms a framework for defining, composing, and executing components or bundles. Think of bundles as the implementation of plug-ins. The term plug-in is used historically to refer to components in Eclipse and is used throughout the documentation and tooling.
There are no fundamental or functional differences between plug-ins and bundles in Eclipse. Both are mechanisms for grouping, delivering, and managing content. In fact, the traditional Eclipse Plugin API class is just a thin, optional layer of convenience functioning on top of OSGi bundles. To Eclipse, everything is a bundle. As such, we use the terms interchangeably and walk around chanting, "A plug-in is a bundle. A bundle is a plug-in. They are the same thing."
It is convenient to think of the OSGi framework as supplying a component model to Java; that is, think of it as a facility at the same level as the base JRE. OSGi frameworks manage bundles and their code by managing and segmenting their classloading—every bundle gets its own classloader. The classpath of a bundle is dynamically constructed based on the dependencies stated in its manifest. The manifest defines who a bundle is and on whom it depends. All bundles are self-describing.
The MANIFEST.MF shown in Figure 2–5 gives the org.eclipse.ui plug-in a plug-in id, or bundle symbolic name, and a version. Common practice is to use Java package name conventions such as org.eclipse.ui for the identifier and [major.minor.service.qualifier] tuples for the version number. The id and version are paired together to uniquely identify the plug-in. The pairs are then used to express dependency relationships. You can see this in the Require-Bundle header of the manifest—the UI plug-in requires the Runtime, JFace, and SWT plug-ins.
Figure 2–5 Plug-in manifest
In the context of Eclipse, the OSGi framework’s main role is to knit together the installed plug-ins, allowing them to interact and collaborate. The rigorous management of dependencies and classpaths enables tight and explicit control over bundle interactions and thus the creation of systems that are more flexible and more easily composed.