Community
Participate
Working Groups
Created attachment 169398 [details] Plug-in Dependencies Graph It looks like the org.eclipse.wst.xsl.jaxp.* plugins, that are included in the org.eclipse.wst.xsl.feature, have dependencies to a set of org.eclipse.jdt.* plugins (see the attached screenshot). This causes a problem in the Javascript EPP package that includes the org.eclipse.wst.xsl.feature. See bug 310282. This dependencies adds a the set of JDT plugins in the JavaScript installation. This not only increases the size of the package, but also pollutes the UI of the IDE with unnecessary Java stuff. Since JAXP stands for Java API for XML Processing, it looks natural that the xsl.jaxp plugins have dependencies to some JDT plugin. But I guess it is possible to move these xsl.jaxp plugins in a separate feature, so we still have XSL in the Javascript EPP, but no XSL.JAXP and hence no JDT.
(In reply to comment #0) > Created an attachment (id=169398) [details] > Plug-in Dependencies Graph > > It looks like the org.eclipse.wst.xsl.jaxp.* plugins, that are included in the > org.eclipse.wst.xsl.feature, have dependencies to a set of org.eclipse.jdt.* > plugins (see the attached screenshot). > > This causes a problem in the Javascript EPP package that includes the > org.eclipse.wst.xsl.feature. See bug 310282. This dependencies adds a the set > of JDT plugins in the JavaScript installation. This not only increases the size > of the package, but also pollutes the UI of the IDE with unnecessary Java > stuff. > > Since JAXP stands for Java API for XML Processing, it looks natural that the > xsl.jaxp plugins have dependencies to some JDT plugin. But I guess it is > possible to move these xsl.jaxp plugins in a separate feature, so we still have > XSL in the Javascript EPP, but no XSL.JAXP and hence no JDT. The problem here is that if you don't include the jaxp feature, you do not get Launching/Debugging for the XSL plugins. There is bug 271672 that requests a new jaxp.feature for xsl. This would allow just the editor to be included but no launching support. The bigger issue is the way the java debug framework which the xsl.jaxp functionality is setup. You get all of JDT because of a jdt.debug.ui dependency on jdt.ui which brings in the full JDT editor as well. There is an open bug against JDT asking for a cleaner separation, see bug 170394.
*** Bug 310282 has been marked as a duplicate of this bug. ***
This is a problem for us as well. We'd like to support simple Web Editing workflows, including JavaScript and PHP Editing. The XSL feature is currently listed as a dependency - but we don't want or need JAXP nor XSL Launching or Debug. Would it be possible to split the XSL feature into a part that just contains the core infrastructure needed by JSDT / PDT, and another part adding the XSL Debug and JAXP capabilities ?
A work around until I get this solved officially is to create a feature that only contains the following bundles: org.eclipse.wst.xsl.core org.eclipse.wst.xsl.ui org.eclipse.wst.xpath.core org.eclipse.wst.xpath.ui This will give you the editor and content assistance, as well as the XPath View and the XPath templates used by the xsl editor for content assistance.
