Community
Participate
Working Groups
The XSLT launcher configuration only looks for .xml files. This should look based on Content-Type, and allow for editing that appears either directly or indirectly under the XML Content type. To reproduce: 1. Create an XSD file. 2. Create a new launch configuration for an XSL debug/launching configuration. 3. Select Workspace for the XML Input. 4. The XSD file that was created is not one of the available options. Again, we should be going off of Content-Type or not have filtering. The reason being is that XSLT 2.0 can work with Text files as input without having to have XML files be the drivers. We should also allow for the input to come from a URI. As input could be driven off an XQuery database that publishes it is accessible from the web as well.
I'll take a shot at this, for 0.5M5
The issue. The XSL launch configuration only looked for xml or xhtml for the input files. The solution. Use the Platform.getContentTypeManager() to retrieve a contentTypeManager, and then get the content Type file extensions that are under the main org.eclipse.wst.xml.core.xmlsource for the content type. This correctly allows xml, xhtml, wsdl, xsd, xsl, etc. Basically any extension that falls under the XML Content type can be used as input for a launch configuration.
Mass Migration to wtp.inc.xsl
This is only showing XML content types, and not any sub content types.
Somehow it was only looking at the org.eclipse.runtime.core.xml content type, instead of the xmlsource content type. The later is the one that is needed so that it correctly picks up all sub type extensions. I've added a unit test so that it tests for this and makes sure that we get at least the xml, xsl, and xslt extensions returned.
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
