There are actually three configurations possible depending on the intent of the user/developer
- Pure Bundle Developer: They need org.eclipse.osgi on their classpath. This contains all of the API for OSGi (and only that API).
- Eclipse Bundle Developer: They should have org.eclipse.core.runtime.osgi on their classpath. This reexports org.eclipse.osgi as well as adding some old runtime elements (e.g., IPath, IStatus, ...) and some new stuff (e.g,. ExtensionRegistry, ...)
- Eclipse Plugin Developer: They should have org.eclipse.core.runtime on their class path as usual. This plugin requires and reexports org.eclispe.core.runtime.osgi and (implicitly) its fragment org.eclipse.core.runtime.compatibility as well as org.eclipse.osgi.
The summary here is that org.eclipse.core.runtime should only be on the classpath/requires list of so called "legacy" plugins. New world plugins/bundles should require org.eclipse.core.runtime.osgi.
Note that org.eclipse.core.boot is obsolete in the new world. It contains only one class/package (which has a new name) and is internal. It is safe to include boot on the classpath (there are no conflicts) but at runtime its contents will not be available. Ideally we want boot to go away.
Dejan Glozic/Toronto/IBM@IBMCA Sent by: equinox-dev-admin@xxxxxxxxxxx
10/03/2003 07:06 PM
Subject: [equinox-dev] 'Implicit' plug-ins to add
I took I0930 and unzipped Equinox build on top. Then I started PDE in a
regular build and pointed target platform at the OSGI build. Then I created
'Hello, World' plug-in.
It failed to compile because it could not find org.osgi.framework.Bundle.
When I added plug-in 'org.eclipse.osgi.framework.core' to the list of
required plug-ins, compilation succeeded.
Is the moral of my exercise that 'org.eclipse.osgi.framework.core' is
implicitly required in order to achieve the transitive closure of classes?
Are there other plug-ins/bundles that should be treated this way?