Another possibility is to use the Product Customization
(http://wiki.eclipse.org/index.php/Product_Customization) features.
I'm not at all familiar with implementing the transformations, but
the gist of it is to allow on-the-fly adjustments to the plugin.xml
files we provide to better suit your product's needs.
Unfortunately, if you're not delivering a discrete product, I don't
think this option is open to you--Oracle's run into this as well
without a clean solution so far.
With the exception of JSDT, most of the components in Source Editing
are as agnostic to project metadata as possible (even the JSP
component). The dependency on Facets is optional at runtime where
possible in Source Editing, but dependencies from WTP Common may
themselves have hard requirements on Facets. Our linkage to
wst.validation should loosen up in 3.2 and in turn remove the
transitive dependency on Facets. In general I'm still intending to
keep the functionality in org.eclipse.wst.xml.ui in the one plug-in
for simplicity.
As for the specific items mentioned:
* Bug reports and fixes for the validation property tester would be
most useful in correcting its over-visibility on file types it
doesn't support.
* The Faceted Project wizard's not one that I know of, but
Konstantin's focus is for new features to be worked on in the
Technology project Incubator, http://www.eclipse.org/fproj/ . It's
unclear to me what practical purpose it serves other than as a testbed.
* Shortcuts should be limited to WTP's perspectives, if not, bug.
The only exception should be shortcuts to our perspectives from others.
* I'd suggest you keep org.eclipse.wst.dtd.*, as it provides the DTD
model used by the XML Editor's content assist. Unless you're 100%
certain your users will only ever use XML Schemas, and if you are
certain, I'd still disagree with you :)
--
---
Nitin Dahyabhai
Eclipse WTP Source Editing
IBM Rational