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.
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 ../lib/ext/xerces.jar construct. 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 ***