Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 26642 - Create Xerces library
Create Xerces library
Status: RESOLVED DUPLICATE of bug 25868
Product: ide
Classification: Unclassified
Component: libs
3.x
PC Linux
: P3 (vote)
: 3.x
Assigned To: issues@ide
issues@ide
:
Depends on:
Blocks: 17815
  Show dependency treegraph
 
Reported: 2002-08-20 15:53 UTC by _ pkuzel
Modified: 2003-02-19 15:11 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2002-08-20 15:53:34 UTC
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).
Comment 1 Jesse Glick 2002-08-20 17:32:25 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.
Comment 2 _ lkramolis 2002-08-22 17:41:01 UTC

*** This issue has been marked as a duplicate of 25868 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo