Bug 27421

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