In issue #25539 I integrated Xerces 2.0.2. It
would be helpfull to expose it as library as well
so modules could declare explicit dependency.
Unfortunately Xerces library wrapper module cannot
directly reference binary in core because manifest
Class-Path attribute does not allow
I could solve it by declaring that core provides
token "Xerces_library_hack" and the library would
require it. Then no jar copy is needed as core
xerces is at classpath. I would not consider it as
core public contract, once Xerces is removed then
library can bundle it directly.
Another issues is external libraries versioning.
Should we follow current approach and provide only
last stable library or should we provide several
versions? I incline to follow current approach
because I expect that most libraries follow
backward compatability rule. I also expect that
all modules want automatically use latest library
versions. If not then they can use isolating
classloader and bundle their library version with
module (i.e. bloating explicit module only).
Core xerces.jar is not on the effective classpath for modules unless
they explicitly declare a package dependency on it. Currently I think
this is not transitive either, i.e. if the libs/xerces module declares
such a package dependency, that does not expose lib/ext/xerces.jar to
modules that depend on it.
We could try bundling only crimson.jar with core - this is all JDK 1.4
supplies anyway, and probably all core needs - and other modules (e.g.
Ant) can try using a separate Xerces if they want it, using an
autoload module. This would make sense for the platform since xerces
is much bigger than crimson. Also the core typically only uses SAX
parsers, which is a bit faster with crimson (last anyone checked).
Note that a package dependency on xerces from an old module (e.g. ant)
could be automatically translated to a module dependency on a xerces
autoload, if we made such a change, so it need not be incompatible.
"I incline to follow current approach because I expect that most
libraries follow backward compatability rule.": I agree.
*** This issue has been marked as a duplicate of 25868 ***