This article describes a work-around for a bug in Eclipse PDE when dealing with inter-fragment dependencies.
I was kicking the tires of OnPositive.com’s Rich Text Editor for Eclipse RCP apps that has been submitted to the Nebula custom widgets project. OnPositive felt the need to extend SWT to provide an extended
StyledText, amongst other things, which they accomplished by using a fragment. Unfortunately pulling in their code into Eclipse JDT/PDE produces masses of class-not-found errors on common SWT classes. It turns out this is due to limitations in the PDE in resolving dependencies between fragments.
The problem arises as SWT is itself implemented using fragments. For SWT, the main plugin
org.eclipse.swt is simply a shell; the real SWT functionality is provided by per-platform and per-windowing-system fragments. For example, all of the MacOS X Cocoa widgets are defined by the fragment
org.eclipse.swt.cocoa.macosx. Unfortunately PDE doesn’t seem to resolve dependencies using the other fragments of the host bundle (though they are properly resolved by Equinox/OSGi at runtime), and thus loading in the OnPositive fragments results in hundreds of class-not-found errors on SWT classes.
This problem can be worked around by explicitly modifying the JDT classpath to
depend on the SWT fragment’s jar file. You can create your own “User Library” using Preferences → Java → Build Path → User Libraries to define a library that includes the SWT jar (I imaginatively called mine “SWT”). Then, for each of the problematic fragments, modify the project properties’s build path to include your new library: project → Properties → Java Build Path → Libraries, then Add Library…, select “User Libraries”, and your new “SWT” library. Your dependencies should now be resolved.
You should note that using the PDE PDE Tools → Update Classpath… will reset the project classpath, and require re-applying this workaround.
I couldn’t find a previous bug against this, so I submitted a new bug as bug 296597.