The current UIMA Eclipse plugins (runtime, CDE, etc.) use "Imported Packages" for declaring dependencies instead of "Required Plug-ins". This declaration is automatically generated by Maven (I think ?) and gives more fine grained controls on what to depend on.
But, there are some side-effects from this approach which may cause the problems. The imported packages may wired to the correct packages from the "wrong" plugins.
If there are, for example, two bundles (plug-ins) A and B export the "same" package name and B is resolved before A, OSGi will pick B bundle for wiring.
This wrong wiring issue is happen when I tested CDE and DDE with Eclipse 3.2 in Linux Redhat 5 (Note that the problem can be happen with any Eclipse and platform). The following describes this particular case.
CDE uses an Xml editor for source editing and this Xml editor requires a class called:
"org.eclipse.jface.text.source.SourceViewerConfiguration" from "org.eclipse.jface.text" plugin
Inside Eclipse installation, there is another plugin called "org.eclipse.text" that also exports this "org.eclipse.jface.text.source" which doesn't have the class "SourceViewerConfiguration".
When Eclipse runs, the "org.eclipse.text" plugin is resolved before the "org.eclipse.jface.text" plugin which causes CDE to be wired to the "org.eclipse.text" plugin. The expectation is to wire CDE to "org.eclipse.jface.text.source".
One possible resolution is posted by Marshall in response to the thread in uima-dev:
[UIMA eclipse plugins] Possible WRONG wiring between UIMA Eclipse plugins
The following is the quote:
On Fri, Mar 14, 2008 at 4:58 PM, Marshall Schor <email@example.com> wrote:
OSGi does provide a mechanism to have the import-package include
specifying which bundle it should come from. See section 3.6.8
"Provider Selection" in the r4.core.pdf doc for OSGi for details.
The POMs we use don't generate this though. Do you see that allowing
multiple bundles to export the same package name, and then having our
configuration be more explicit about which bundle to wire to, is (or may
be) a design requirement?