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.
Summary: | Create Xerces library | ||
---|---|---|---|
Product: | ide | Reporter: | _ pkuzel <pkuzel> |
Component: | libs | Assignee: | issues@ide <issues> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | issues, issues, jglick |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 17815 |
Description
_ pkuzel
2002-08-20 15:53:34 UTC
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 *** |