Bug 27421 - Keep XML libraries up-to-date
Keep XML libraries up-to-date
Status: NEW
Product: ide
Classification: Unclassified
Component: libs
3.x
All All
: P2 (vote)
: TBD
Assigned To: issues@ide
issues@ide
issue_reviewed
: ARCH
Depends on: 35762 38301
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-18 15:29 UTC by _ lkramolis
Modified: 2010-12-09 16:28 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ lkramolis 2002-09-18 15:29:37 UTC
Currently, NetBeans bundles JAXP 1.1, Xerces 2.0.2
and Xalan 2.3.1 libraries, which are already
obsolete by new bug fixing or API maintenance
releases.

For mentioned API there is integrated source
editor code completion database and is mounted
javadoc in XML modules.

Keep bundled libraries up-to-date and integrate
last stable releases of it.
Comment 1 _ lkramolis 2002-09-18 15:45:48 UTC
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.
Comment 2 Jesse Glick 2002-09-20 03:45:21 UTC
"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?)
Comment 3 _ lkramolis 2002-09-20 08:22:11 UTC
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.
Comment 4 _ lkramolis 2002-09-27 10:36:55 UTC
Xerces 2.2.0 released: <http://xml.apache.org/xerces2-j/releases.html>.
Comment 5 Jesse Glick 2002-09-30 05:53:50 UTC
"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.
Comment 6 Jiri Prox 2007-09-17 20:48:29 UTC
Obsolete milestone, please reevaluate


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