Community
Participate
Working Groups
Who is affected: Plug-ins which declare classpath entries in their plugin.xml file but where the actual jars are intended to be supplied by fragments to the plug-in. Description: Standard Eclipse manages fragments by seamlessly merging the entries in their fragment.xml files with those of the host plug-in's plugin.xml file. For example, at runtime only the host has a classloader. This classloader loads the classes from the plug-in as well as all the fragments. This leads to situations where the host specifies a classpath entry such as "$ws$/swt.jar" but does not in face supply the swt.jar. The new fragment model sees fragments as first class entities which have classloaders of their own (if needed) but yet delegate class/resource discovery to the classloader of their host prior to consulting their own classpath. This is functionally equivalent to the standard Eclipse approach but leads to a difference in the classpath setup. Under this model, there is no reason for the host to specify a vacuous classpath entry. Rather, it should remain silent about jars potentially supplied by fragments and leave them to specify their own classpath. Analysis: The current Eclipse behaviour is somewhat anomalous in that the runtime and the tooling have to take exceptional measures when computing the classpath related to a set of fragments and their host plug-in. The new approach simplifies this. The only place where we have seen this issue is in the SWT plug-in and fragments. The unfortunate side-effect of this change is that it makes it hard to generate the bundle manifests corresponding to the plugin.xml and fragment.xmls. The current Equinox runtime relies on the SWT elements including hand-crafted manifest files with the characteristics outlined above. Technical notes: The Equinox team is investigating enhancing the plug-in converter to analyze potential cases and generate the appropriate classpath entries in the bundle and fragment manifests.
see also bug 44230 As stated in bug 44230, the Equinox behviour described in comment 1 is not functionally equivalent. Code from a fragment cannot see package visible code in the same package but in the plugin. This is because the two packages are loaded by different classloaders and so are in fact different packages. The migration doc will be updated to reflect this. The only reasonable workaround we can see at this time is to change the implementation of fragments to put their code elements on the host's classloader. This matches the Eclipse behaviour, reduced classloader cycles but also couples fragments and hosts more tightly.
The fragment model has been updated and fragments are now merged onto their hosts. Closing.
