I don't think it can work. If I use XMLUtil to get a DOM parser, it
gives me Crimson. Crimson's Document does not implement EventTarget,
which I need. Xerces' Document does implement the DOM event model, but
of course if the code is to use JAXP and be independent of parser then
I cannot ask for Xerces' parser. What can I do?

Is it really necessary, or just desirable, to remove the dependency on
DOMParser? If xerces.jar will continue to be on the classpath, and it
still contains similar functionality, ant & apisupport could continue
to work while depending on the presence of the Xerces parser. From
what I can see, Xerces 2.0.0 retains the same package naming for the
parser impl. We could get rid of the dep when the TAX API is ready for
outside use.

Created attachment 4655 [details]
Patch which does not work: ClassCastException, Crimson's Document impl does not implement EventTarget

DOMParser was not backward compatible in Xerces, last time I tested
it.

How so? Assuming we compile against Xerces 2.0.0. At least there is a
class with the same name, I didn't check its signature.

Signatures look good except superclass that matters:
http://nbbuild.netbeans.org/issues/show_bug.cgi?id=19682

Also I am not sure if xerces will continue to be at classpath. Relying
on classpath proved to be problem as there also lies unknown higher
priority implementations in jre/lib/rt.jar, jre/lib/ext and
jre/lib/endorsed.

I see your point. In that case I should work on #19622 first so that
ant + apisupport can ask for a private Xerces impl. Hopefully TAX will
mean we will not have to release them in this configuration.

Alternate idea: just like NbSAXParserImpl provides an NB-specific SAX
preference list, maybe we could do the same for DOM parsers. Xerces
seems much more useful for DOM-based apps than Crimson because it has
fuller feature compliance. It is unpleasant to ask JAXP for a DOM
parser with both Crimson and Xerces on the classpath, and to get
Crimson's.

Alternate idea comment: It is addressed by #19682.

Probably best committed as part of #13904, I guess. The attached patch
should work well enough and leave you free to update the core-supplied
XML libraries.

You have to use new org.apache.xerces.dom.DocumentImpl(), because
XMLUtil uses JAXP that is configured by core, so it can return
arbitrary DOM implementation selected by core developers.

org.apache.xerces.jaxp.DocumentBuilderFactoryImpl I guess you mean.
Ought I then declare a package dependency on Xerces packages? I guess
so. Or is there some module which will "provide" Xerces? I have lost
track of what is going on with the parsers...

It is up to you which approach you choose. Your goal is to get
explicit DOM implementation. It is exactly same as current usage of
new DOMParser(). I works while Xerces2.0.1 is at classpath. To be sure
you need to declare explicit dependecy. Now you have exactly the same
problem as in #20289.

Sorry #20269 is correct one.

More or less fixed. The new code first tries to make a
DocumentBuilderFactory using JAXP. It tests it to see if its Document
implementation is assignable to EventTarget. If this fails e.g.
because it is getting Crimson, it tries again by loading the Xerces
impl (using reflection), which will only work if that impl is on the
classpath. If that also fails, layer structure editing will not work.

Note that the Xerces 2.0.1 parser seems to have fixed the lazy node
expansion bug I found in a 1.x parser, but has a new bug which affects
parse-regenerate code and which I can only crudely work around: after
parsing a document with a DOCTYPE, if the included DTD contained any
comments, they appear in the parsed document, between the DOCTYPE and
the root node. Workaround: delete any comments found in this position
immediately after parsing.

committed   * Up-To-Date  1.62        apisupport/manifest.mf
committed   * Up-To-Date  1.13       
apisupport/src/org/netbeans/modules/apisupport/layers/ParseRegen.java