Community
Participate
Working Groups
When installing org.eclipse.wst.feature(.feature.group) into an RCP platform, although the feature doesn't declare that it installs JDT, the JDT UI and dependencies are installed as plugins. Note that the Eclipse XML Editors and Tools (org.eclispe.wst.xml_ui.feature(.feature.group)) does not do this on its own. I don't see any need for the XSL tools to depend on JDT UI, but I suspect P2 is picking up on some (optional?) dependency and then transitively installing the contents.
We are working to separate these into distinct installable features. For launching and debugging support we do require some items from the JDT be around (i.e. classpath support), but for editing there are no dependencies that are necessary from JDT. See bug 271627 for further discussion. *** This bug has been marked as a duplicate of bug 271627 ***
Can we use this bug for cleaning up the manifest, which will prevent bringing in JDT UI, and leave the idea of a separate feature for a later release? That way, this can be targetted for a service release whereas a featre re-org may not be.
(In reply to comment #2) > Can we use this bug for cleaning up the manifest, which will prevent bringing > in JDT UI, and leave the idea of a separate feature for a later release? That > way, this can be targetted for a service release whereas a featre re-org may > not be. The problem is that currently the XSL Feature includes the JAXP debugging plugins and it is what is bring in the JDT dependency, due to the class path usage. Seperating out the features is the way to work this out, if you can point me to a particular xsl plugin's manifest that has the JDT ui dependency (that isn't in the jaxp plugins), I can create a patch.
From bug 271627 comment 19: "But, after reading it, I was curious. So I looked/searched the XSL plugins I have loaded in my workspace, saw one code bundle (and one test bundle) that had o.e.jdt.debug and o.e.jdt.debug.ui in the manifest.mf, I removed them ... and was surprised it caused no compile errors! I also searched through their *.java files, and didn't hit anything, so don't think there's any reflection with strings being used?" From the P2 file: <unit id='org.eclipse.wst.xsl.debug.ui' version='1.0.200.v201101281837'> <required namespace='osgi.bundle' name='org.eclipse.debug.ui' range='[3.5.0,4.0.0)'/> <unit id='org.eclipse.wst.xsl.ui' version='1.1.200.v201103082057'> <required namespace='osgi.bundle' name='org.eclipse.debug.ui' range='[3.3.100,4.0.0)'/> <unit id='org.eclipse.wst.xsl.jaxp.debug.ui' version='1.0.200.v201103081922'> <required namespace='osgi.bundle' name='org.eclipse.debug.ui' range='[3.4.0,4.0.0)'/> I may have missed some (reading P2 can really do your head in) but these are probably the ones to fix; you can then test to see if an install of the XSL feature into an RCP draws in JDT UI or not :) Is XSL on git yet?
(In reply to comment #4) > From bug 271627 comment 19: > > "But, after reading it, I was curious. So I looked/searched the XSL plugins I > have loaded in my workspace, saw one code bundle (and one test bundle) that had > o.e.jdt.debug and o.e.jdt.debug.ui in the manifest.mf, I removed them ... and > was surprised it caused no compile errors! I also searched through their *.java > files, and didn't hit anything, so don't think there's any reflection with > strings being used?" > > From the P2 file: > <unit id='org.eclipse.wst.xsl.debug.ui' version='1.0.200.v201101281837'> > <required namespace='osgi.bundle' name='org.eclipse.debug.ui' > range='[3.5.0,4.0.0)'/> > > <unit id='org.eclipse.wst.xsl.ui' version='1.1.200.v201103082057'> > <required namespace='osgi.bundle' name='org.eclipse.debug.ui' > range='[3.3.100,4.0.0)'/> > > <unit id='org.eclipse.wst.xsl.jaxp.debug.ui' > version='1.0.200.v201103081922'> > <required namespace='osgi.bundle' name='org.eclipse.debug.ui' > range='[3.4.0,4.0.0)'/> > > I may have missed some (reading P2 can really do your head in) but these are > probably the ones to fix; you can then test to see if an install of the XSL > feature into an RCP draws in JDT UI or not :) I'm going to commit this weekend, the patch that is on bug 271627, and then will provide a P2 repo link where you can test the installation. The only one that will require a JDT dependency will be the jaxp launching support, everything else won't. In fact, you'll only require the xsl editor feature if all you are interested in is XSL editing. > > Is XSL on git yet? No, not really, the only thing that is available are the git mirrors of cvs. WTP is still on CVS, and right now there are no plans to move yet. (I'm working on convincing them though. :) ). git://dev.eclipse.org/org.eclipse.webtools/sourceediting.git
Can we at least fix the manifests for the 3.7.1 release later this year? I suspect a feature re-org wouldn't make it into the service release; am I correct? Pulling in JDT core I'm less worried about, I just don't want to pull in JDT UI. Though pulling in neither would be great.
(In reply to comment #6) > Can we at least fix the manifests for the 3.7.1 release later this year? I > suspect a feature re-org wouldn't make it into the service release; am I > correct? > > Pulling in JDT core I'm less worried about, I just don't want to pull in JDT > UI. Though pulling in neither would be great. The only two places that JDT is referenced, is in the org.eclipse.wst.xsl.jaxp.debug.ui and org.eclipse.wst.xsl.jaxp.launching jaxp.debug.ui could have the dependency removed, but jaxp.launching is still part of the feature so JDT will be brought in. JAXP requires org.eclipse.jdt.launching otherwise it will have compilation errors, and it is JDT launching that brings in the rest of JDT UI.
