Description Wassim Melhem 2003-11-07 03:11:08 EST

Build: N-20031107

I have all plug-ins imported as binary in my workspace and I have 
org.eclipse.debug.ui checked out from CVS.

I open to the dependencies tab of the debug.ui plugin.xml, and I select 'Find 
Unused dependencies'.  The function then tells me that org.eclipse.help is not 
being used.  Behind the scenes, this function actually used Java search and 
determined that none of the Java types declared in org.eclipse.help are 
directly referenced by org.eclipse.debug.help, and thus declared it to be an 
unused dependency.

Here is where it gets interesting:
Delete the org.eclipse.help dependency and save the manifest file.  PDE then 
updates the classpath accordingly and all of a sudden you will see an error in 
the problems view saying that org.eclipse.debug.ui cannot be built because the 
class file for org.eclipse.help.IContext cannot be found on the classpath.

It turns out that the LaunchConfigurationView (from debug.ui) imports 
org.eclipse.ui.workbench.WorkbenchHelp(from org.eclipse.ui.workbench), which, 
in turns references org.eclipse.help.IContext (from org.eclipse.help).

So PDE obviously did not think org.eclipse.help was needed because none of its 
types are directly referenced in debug.ui's classes.  However, if 
org.eclipse.help is not on debug.ui's classpath, the JDT compiler complains 
that debug.ui is indirectly referencing a class that is not on its classpath..

cc'ing Philippe and Jim to answer the following questions, respectively:
1. Must org.eclipse.help be on debug.ui's classpath for successful compilation 
or is this a compiler bug?  My guess is that it is not a bug.
In which case, Jim,
2. Should org.eclipse.ui.workbench then reexport its dependency on 
org.eclipse.help so that clients of the very popular WorbenchHelp class do not 
have to explicitly list org.eclipse.help as a dependency.