This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Currently, NetBeans bundles JAXP 1.1, Xerces 2.0.2 and Xalan 2.3.1 libraries, which are already obsolete by new bug fixing or API maintenance releases. For mentioned API there is integrated source editor code completion database and is mounted javadoc in XML modules. Keep bundled libraries up-to-date and integrate last stable releases of it.
Resolve also JAXP module dependency on implementations' modules. What is relation to lib/ext/xml-apis.jar? Should we still rely on it? Should not we bundle own instance of this jar? Should the JAXP module still rely on lib/ext/xerces.jar? Should not we change dependency on Xerces module? -- Xerces module could PROVIDE "javax.xml.parsers". Xalan module could PROVIDE "javax.xml.transforms". Appropriate modules could also PROVIDE implementation specific "tokens", e.g. org.apache.xpath.XPathAPI or org.apache.xml.serialize.XMLSerializer.
"What is relation to lib/ext/xml-apis.jar? Should we still rely on it? Should not we bundle own instance of this jar?" - bundle own instance? It is an official API JAR...so what do you mean? "Xerces module could PROVIDE "javax.xml.parsers"." - would recommend that it provide the class name of the actual factory, e.g. javax.xml.parsers.SAXParserFactory (or whatever it is). org.apache.xml.serialize.XMLSerializer as a token - this makes little sense to me, since to use it you need a compile-time dependency on it. I might suggest ripping org.apache.xml.serialize.* out of xerces.jar altogether and offering it as an independent autoload. Not sure if this is wise, but would simplify some things. (Of course, the serializer will be obsoleted by DOM3 anyway, right?)
Re "bundle own instance": There are already two "instances" of xerces.jar. Here I am not sure if core team want so offen change of xml parser (lib/ext), maybe that they need just any stable parser and they do not need to changed it till known (for NetBeans) bug fixing. While modules parser (modules/autoload/ext) should be up-to-date because modules want to use modern XML parser. So it is possible that modules/autoload/ext will not be same version of same library. JAXP 1.2 was released and next Xerces and Xalan releases could support it. And it is what I wrote about -- that would need new xml-apis.jar for autoload modules, i.e. second "instance" of XML APIs. But here it depends on if core want to have xml parser updated so offen -- all NB can be affected. I can imagine upgrade of parsers will not be synchronized. -- You are right, I agree with factory class as provider name. -- Regarding to serializer, it is not so simple. I am not sure if lawyers understand that part of binary distribution will be separated to different jar.
Xerces 2.2.0 released: <http://xml.apache.org/xerces2-j/releases.html>.
"Here I am not sure if core team want so offen change of xml parser (lib/ext), maybe that they need just any stable parser and they do not need to changed it till known (for NetBeans) bug fixing. While modules parser (modules/autoload/ext) should be up-to-date because modules want to use modern XML parser." - IMO core always wants the latest released version of each XML parser. Core and most modules only use the impls of official XML APIs, i.e. JAXP, so any released version of the parser should suffice, unless it has some critical bug (in which case we should ask them to make a dot-dot release, and bundle that instead). We should be resistant to letting modules depend on less-official APIs from such libraries, as they are less likely to be stable - a module should have to justify any use of a special library version very careful and do a complete analysis of how it will be used and upgraded. Note that upgrading a library generally counts as a non-bugfix change. Thus, during high-resistance mode, libraries should not be upgraded - NB should ship with the last release made before we entered high-resistance mode. In a few cases, a new lib release will include some critical bugfix.
Obsolete milestone, please reevaluate