Section 26.6.  Singletons

26.6. Singletons In general, Eclipse is able to concurrently run multiple versions of the same plug-in. That is, org.eclipsercp.hyperbola version 1.0 and 2.0 can both be installed and running at the same time. This is part of the power of the Runtime's component model. Dependent plug-ins are bound to particular versions of their prerequisites and see only the classes supplied by them. There are cases, however, where there really should be only one version of a given plug-in in the system. For example, SWT makes certain assumptions about its control over the display and main thread. SWT cannot cohabitate with other SWTs. More generally, this occurs wherever one plug-in expects to have exclusive access to a global resource, whether it be a thread, an OS resource, a network port, or the extension registry namespace. To address this, OSGi allows a bundle to be declared as a singleton. The bundle in the example below is marked as a singleton. This tells OSGi to resolve at most one version of the bundle. All other version constraints in the system are then matched against the chosen singleton version. org.eclipse.core.runtime/MANIFEST.MF Bundle-SymbolicName: org.eclipse.core.runtime;singleton:=true Bundle-Version: 3.1.0 The most common reason to mark a plug-in as a singleton is that it declares extensions or extension points. The extension registry namespace is a shared resource that is populated by bundle ids. If we allowed multiple versions of the same bundle to contribute to the registry, interconnections would be ambiguous. By default, bundles that declare extensions or extension points but do not have a MANIFEST.MF are marked as singletons. If you have a MANIFEST.MF, you should annotate it accordingly.