Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351431

Summary:	Installing XSL tools installs JDT UI as well
Product:	[WebTools] WTP Source Editing	Reporter:	Alex Blewitt <alex.blewitt>
Component:	wst.xsl	Assignee:	Project Inbox <wst.xsl-inbox>
Status:	REOPENED ---	QA Contact:	David Carver <d_a_carver>
Severity:	normal
Priority:	P3	CC:	thatnitind
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:

Description Alex Blewitt

2011-07-07 08:01:03 EDT

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.

Comment 1 David Carver

2011-07-07 09:13:13 EDT

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 ***

Comment 2 Alex Blewitt

2011-07-07 10:08:41 EDT

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.

Comment 3 David Carver

2011-07-07 11:04:57 EDT

(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.

Comment 4 Alex Blewitt

2011-07-07 11:28:02 EDT

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?

Comment 5 David Carver

2011-07-08 10:43:30 EDT

(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

Comment 6 Alex Blewitt

2011-07-08 11:09:52 EDT

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.

Comment 7 David Carver

2011-07-08 17:21:59 EDT

(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.