Community
Participate
Working Groups
We've long had the ability that someone could install only the XML features from our update site. (Throughout, I mean "XML" to include DTD, XSD, XSL, and XML) To make this into a complete "product" however, some additional items would help: Capabilities bundle: I suggest a small plugin to define the XML capabilities in. We currently have some capabilities in "org.eclipse.wst" plugins that should be in their own bundle for this specific sort of limited install. Product plugin: Long term, we'd want a "branding" plugin and product configuration file which could hold icons, a splash screen, initial perspective, etc. XML IDE feature: I suggest the name org.eclipse.wst.xml.ide.feature (not sure we really need an org.eclipse.wst.xml.ide_sdk.feature, but maybe, just for symmetry). The XML ide feature would, basically, just include the capabilities bundle and the product plugin _and_ the existing XML and XSL features. It would exist mostly for easier building and packaging on our download page. Those adopting us in larger products (and indeed, even larger deliverables from WTP) would not include any of these bundles or ide feature ... they would just include the "meaty" part of the component (which already exists). The actual list of capabilities, though, would be merged in similar capabilities bundles in those larger products. I could do the basic features, but someone else would have to fill in meaningful capabilities.
The only potential problem I can see (other than actually getting the thing organised) is the fact that in order to run a transformation we need the JDT installed, which means of course we would get the Java persective and all the other associated stuff. Do you think thats acceptable for a first release of this package? The alternative is to not bundle the JDT, in which case we get most of the XSLT capability, but you just can't run a transformation.
I don't think you can say you support XSL if you can't run a transformation so if you release an XML package without that it's probably better not to mention anything relating to XSLT. If you consider language neutral IDEs they just give you some means to launch your own parser if you desire, maybe all that's needed is that plus an easy way to install the Java functionality for those are using XSLT with Java.
Well, there is an extension point so that others can add their own command line based parsers. Or people can use the External Tools dialog to launch XSL Transformations. We may just need to document how to use the External Tools for launching transformations. Ideally we would have bug 170394 addressed so that plugins could use the java runtime support with out needing to bring in all of JDT.
Well, there is an extension point so that others can add their own command line based parsers. Or people can use the External Tools dialog to launch XSL Transformations. We may just need to document how to use the External Tools for launching transformations. Ideally we would have bug 259196 addressed so that plugins could use the java runtime support with out needing to bring in all of JDT.
(In reply to comment #4) > We may just need to document how to use the External Tools > for launching transformations. I think this would be the way to go. Having a standalone XML product is a great idea - I was thinking about it myself mainly to have file associations the way Aptana does. The most important thing (to me) is to be able to double click XML/XSD/XSL/X-Whatever files and have them open up with as much functionality available as possible. Eclipse is a really nice framework but often leads a lot to be desired when it comes to usability. Most people won't want to mess with creating projects or configuring things. Which leads me to a second point - adding new plugins to Eclipse is still quite involved and confusing. If I was a Java/XML developer I would really like the standalone product to tell me the Java functionality can be added and give me an easy way to do it.
