Community
Participate
Working Groups
The current org.eclipse.wst.xsl.launching plugin has dependencies on the JDT. We should not require JDT be installed for the launching component, as this will require JDT be installed for any adopter that wants to use the XSL launching ability. This restriction adds a piece that doesn't need to be there. Development envirnonments like RadRails, PHP, Perl, etc, may not want to have JDT installed, but still want to offer XSL editing support. This is also crucial for those trying to develop a XML IDE and may not want or need the JDT support in their environment.
Perhaps we can do it this way: If JDT is available, we see the tabs for classpath manipulation, profiling, etc. If not, we provide a much simpler launch mechanism based on the JRE executing Eclipse itself (discoverable from System.getProperties, right?)
I like that particular idea. We can keep the dependence on JDT for now, but I think we need to long term not be dependent on it for implementation. Maybe make JDT an optional plugin dependency and as you said gracefully degrade if it isn't there.
With (quite a bit of) work we can disentangle the JDT from launching. It might mean having several launchers - one for Java, one for .Net etc., but it is possible. The important thing right now is that we don't put any JDT dependencies into the rest of our code i.e. the editor, Xpath, validation etc. This should be independent of the target technology.
How about we do the disentangling in stages. At the momement having the dependency is fine, but long term we might want to provide a generic framework that expands the existing launching framework, so that it can be adapted based on the XSLT processor choosen.
Mass Migration to wtp.inc.xsl
*** Bug 238062 has been marked as a duplicate of this bug. ***
This one is going to difficult to work around. I did some preliminary inspection here. These particular tabs are tied heavily into JDT. Even though they look like they could be taken out. I might investigate seeing what would need to be done to remove this for 1.0, but I know it can't be done before then. Targeting this for Future, and adding helpwanted.
Created attachment 108339 [details] XSL Java Launch
Created attachment 108340 [details] XSL Java Preferences
In order to do things in stages, we could first split the XSL feature into two features; one that depends on the JDT and one that doesn't: non-JDT feature (org.eclipse.wst.xsl.feature): xpath.core, xpath.ui, xsl.core, xsl.ui JDT feature (org.eclipse.wst.xsl.java.feature): xsl.debug, xsl.debug.ui, xsl.launching, xsl.xalan, xsl.saxon If you only have the non-JDT feature installed you will get: - All XML and XPath stuff (XML perpsective, XPath templates, XPath view) - All XSL editor stuff (XSL validation, XSL content-assist) - None of the Java launching or debugging The preferences and launch config are then like the 2 attachments I created above. Its a start on breaking the dependencies at least.
(In reply to comment #10) > In order to do things in stages, we could first split the XSL feature into two > features; one that depends on the JDT and one that doesn't: > > non-JDT feature (org.eclipse.wst.xsl.feature): > xpath.core, xpath.ui, xsl.core, xsl.ui > > JDT feature (org.eclipse.wst.xsl.java.feature): > xsl.debug, xsl.debug.ui, xsl.launching, xsl.xalan, xsl.saxon > > If you only have the non-JDT feature installed you will get: > > - All XML and XPath stuff (XML perpsective, XPath templates, XPath view) > - All XSL editor stuff (XSL validation, XSL content-assist) > - None of the Java launching or debugging > > The preferences and launch config are then like the 2 attachments I created > above. > > Its a start on breaking the dependencies at least. This sounds like a good start. I may take a look at the JDT code and see what would be required to break some it out from JDT (the editor/IDE portion) to a common java runtime portion, that contains just the pieces that aren't specific to JDT but could be used by all other plugins that may need it. This way we could depend on a smaller piece of the java.runtime portion instead all of JDT.
I am working on a solution
The parts that do depend on the JDT have been put into separate plugins. Other plugins that don't depend on the JDT (e.g. libxslt, msxml) can now contribute their own launchers.
(In reply to comment #13) > The parts that do depend on the JDT have been put into separate plugins. Other > plugins that don't depend on the JDT (e.g. libxslt, msxml) can now contribute > their own launchers. > This probably needs a separate bug report, but we might be able to create a Feature that we can depend on that only includes the necessary Launching and Debugging features. This way, we can include a very small subset of JDT, for XSL Tooling that needs JAXP launching support for Xalan and Saxon.
*** Bug 248113 has been marked as a duplicate of this bug. ***
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
