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.

Bug 20269 - Remove non-serializer Xerces dependency in Ant module
Summary: Remove non-serializer Xerces dependency in Ant module
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
: 19682 (view as bug list)
Depends on: 20532 25868
Blocks: 13904 20270
  Show dependency tree
Reported: 2002-02-07 16:04 UTC by Jesse Glick
Modified: 2003-12-19 15:13 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Proposed patch (modified files) (12.19 KB, patch)
2002-03-01 09:53 UTC, Jesse Glick
Details | Diff
Proposed patch (ZIP of added files) (4.85 KB, application/octet-stream)
2002-03-01 09:55 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-02-07 16:04:04 UTC
It should not require the Xerces XML parser, though it may continue to use the
serializers package. See AntProjectSupport. Coding should be trivial; mostly
testing and sanity-checking that there are no problems with Xerces 2.0.0.

Basically DOMParser is in use only to turn off the deferred node expansion
feature in an older version of Xerces, which was badly buggy. I think the bug is
now gone, so using JAXP to get the parser and not setting any features will
probably work.

Pay close attention to the DOM mutation events. In my experience, Xerces 1 was
rather buggy about which events it would send, and the listeners needed to be
tuned to work around these bugs.

Use to find out exactly what is going on. Try
modifications text -> Explorer and Explorer -> text and sanity-check.
Comment 1 Jesse Glick 2002-03-01 09:52:09 UTC
OK, I think I have a working patch here. It makes ant & apisupport
modules depend on a new autoload, org.apache.xerces.v13 (stored in
core/xerces13/ in CVS), which just wraps Xerces 1.3.0. I tried it with
JDK 1.3 and 1.4, and tried (1) leaving 1.3.0 on classpath as it is
now, (2) removing Xerces from the classpath, (3) including Xerces
2.0.0 beta 2 on the classpath; no troubles in any case.

Anyone see any problems with this approach?

Note that the patch assumes nbextra/core/release/lib/ext/xerces.jar is
1.3.0, so as not to have to move around extra binaries. If and when
you (pkuzel) commit the patch to upgrade XML parsers, this should be
moved to
and core/xerces13/build.xml updated accordingly.
Comment 2 Jesse Glick 2002-03-01 09:53:27 UTC
Created attachment 4889 [details]
Proposed patch (modified files)
Comment 3 Jesse Glick 2002-03-01 09:55:38 UTC
Created attachment 4890 [details]
Proposed patch (ZIP of added files)
Comment 4 _ pkuzel 2002-04-25 10:23:26 UTC
This bug has survived 13904 fix without uncovering it, but it is still
timed bomb.
Comment 5 David Konecny 2002-04-25 10:39:13 UTC
HA! I admit I forgot about this issue. I'm going to look at it.
Comment 6 _ pkuzel 2002-04-25 10:40:17 UTC
Just discussed with David and suggested to use R/P dependencies. Ant
would require org.apache.xerces.2.0.1 token that would be provided by
core and the Xerces library provided by Ant. Once core discontinues
providing the token then Ant module will seamlessly switch to its own

Does it make sence?
Comment 7 Jesse Glick 2002-04-25 13:30:10 UTC
Still needs org.apache.xml.serialize.* package directly accessed. I
think use of JAXP otherwise would be OK; there is no need to
specifically ask for Xerces 2.x *features*, it is a matter of ensuring
that the supplied parser does not have the critical bugs that I saw in
some 1.x releases (which may have been fixed in some 1.x release).
Comment 8 _ pkuzel 2002-04-25 14:22:31 UTC
Then require token org.apache.xml.serialize.2.0.1?
Comment 9 David Konecny 2002-04-25 14:29:29 UTC
if understand this issue correctly what I should do is:

1.) add into nbextra 

2.) create new autoload module org.apache.xerces.v13

3.) change ant module to depend on this new module and not directly on 

What is not clear to me is where this module should be put? As 
submodule of core? Or top level module? Or XML sub module? From your 
patch it looks that is should be core submodule. I talked with Hrebejk 
and he disagree that it should be under core.
Comment 10 Jesse Glick 2002-04-25 15:49:48 UTC
Petr - requiring some token for the serializer package makes no sense;
you need to depend on it at compile time. That means use of Class-Path
or a regular module dependency.

David - I think we should try to use Xerces 2.x first, and only fall
back to using 1.3.x if 2.x will not work. If we do need to make a
1.3.x autoload module, I guess it could go as a submodule of the xml
project? Don't know. It really doesn't make any difference except
psychologically to the module owners.
Comment 11 David Konecny 2002-04-25 16:26:22 UTC
OK, I tried it with new xerces 2.0 and it seems to work. But only time 
and nbusers will show whether it really works or not. If everything is 
OK with xerces 2.0, then we don't need to provide autoload 1.3 xerces 
module, right? That is good. But with each update of xerces we 
potentially can have some problems, rigth?

I agree that location of the module is just psychological problem. :-)

So, what now? Should I close this issue with LATER resolution, what 
literally means that till some problem appears we don't need to create 
autoload module? Or do you think I should do create autoload module?
Comment 12 _ pkuzel 2002-04-25 16:48:57 UTC
May be I have not understood P/R properly. I originaly thought that it
would add provider resources to requestor classloader search path.

Regarding library hosting we think about establishing xml/lib
subproject for this purpose. Even better we would introduce top level
"libraries" project holding all third party libraries and its wrapper
modules. It would improve library sharing among modules.
Comment 13 Jesse Glick 2002-04-25 17:33:37 UTC
To David: OK, if everything is working as things are, I guess I would
close as REMIND. I don't know of anything wrong with Xerces 2.0 that
would require us to use 1.3. But please read the comments in issue
#20270 first - when I tried it for apisupport, there were big problems
because I got Crimson as the DOM parser, which is not featureful
enough to be used. Has this changed? Is it now sure that an adequate
DOM parser will be served from JAXP?

To Petr: no, part of the *purpose* of P/R dependencies is that they do
not add to the effective classpath. So you can depend directly on an
API/SPI, and require that some unknown provider be present, without
needing to know the provider's identity, nor have that provider
contaminate your classpath (since you should have no compile-time
dependencies on the provider, only the API/SPI).
Comment 14 David Konecny 2002-04-26 13:47:35 UTC
OK. I talked with Petr K. and we agreed that if some problem appears 
we will create autoload module xerces_version_X_X under XML module and 
ant will depend on this concrete version of the xerces.
Comment 15 Jesse Glick 2002-06-28 15:38:26 UTC
*** Issue 19682 has been marked as a duplicate of this issue. ***
Comment 16 Milan Kubec 2002-06-28 16:09:26 UTC
I think that this issue should be fixed since ant module shouldn't
depend on particular XML parser to avoid future problems when IDE will
use next version of XML parser. It already happened when using ant
from nb 3.3.2 in nb3.4 where ant script cannot be parsed. 
Comment 17 Marek Grummich 2002-07-22 08:18:27 UTC
Target milestone was changed from '3.4' to TBD.
Comment 18 David Konecny 2002-07-22 12:52:19 UTC
I'm changing target milestone to 4.0, because I don't dare to do this 
change for NB3.4. I filed issue 25868 for XML module to provide 
NB autoload modules wrapping different versions of xerces. Once the 
issue is implemented the Ant will depend on this module. This seems to 
me as the best solution.
Comment 19 _ lkramolis 2002-07-22 13:21:15 UTC
I would like to ask which version of Xerces do you want to depend on?

1) Any Xerces2 (org.netbeans.libs.xerces)
   (Always last stable release -> just one xerces module will be created.)
2) Xerces 2.0.x (org.netbeans.libs.xerces20x)
   (Any minor changes/fixes 2.0 release -> module for each major
xerces release -- next one will be ...xerces21x.)
3) Xerces 2.0.2 (org.netbeans.libs.xerces202)
   (Concrete release -> module for every xerces release -- xerces203,
xerces204, ...)

Probably, it does not make sense to request 3) -- a lot of modules
should be provided if requested. If you just depend on any xerces
implementation then 1) is the best way. Let me know, what you need.
Comment 20 David Konecny 2002-07-22 13:51:46 UTC
In near future I will need just one for the version of Xercer 
currently used in NB3.4. The Ant module will depend on it and so if 
IDE's parser will change in next version it will not affect the Ant.
Comment 21 _ lkramolis 2002-07-22 14:16:31 UTC
I understand Ant's request very well, but I asked about it because
once I create xerces module I should not remove it because some other
module could depend on it. I think that for each new xerces release
there will be request for upgrade and in the case 3) it means new
module and I am worry about tens of xerces modules.

Probably the case 2) is the best because "you depend on concrete
xerces implementation (e.g. 2.0) and you tolerate minor release
updates (e.g. from 2.0.2 to 2.0.99)".

If you do not depend on xerces API then the case 1) is the best but it
is not your case I think.
Comment 22 David Konecny 2002-07-22 15:08:34 UTC
yes, 2) looks like what I need
Comment 23 Jesse Glick 2002-07-22 18:42:51 UTC
Two alternate suggestions:

1. Do as apisupport currently does, successfully I think: depend only
on the Xerces serializer package, which is entirely independent of the
parser. When getting a parser, ask JAXP, and if it gives you a parser
supporting DOM Events, great. If not, and using post-3.4 (IDE/1 > 3.3
I think - apisupport does not yet do this) ask Lookup for all
DocumentBuilderFactory's available, and select one which supports DOM
Events. If you need to work with APIs pre-3.3 (META-INF/services/*),
then if JAXP fails to give you one, do as apisupport does now and try
to load the Xerces impl of DBF using Class.forName. Thus no dependency
on particular Xerces version other than that (1) Xerces ser library is
available, which IMHO could be made into a separate autoload module
anyway, (2) DOM Events is supported by *somebody*.

2. Do as you are talking about, but using dep style #1, i.e. no
particular dep on specific Xerces features. I think this is the case,
so long as the autoload module makes it possible to get a DBF reliably
from the module (for example, using Lookup).

BTW Petr/Libor: now that Lookup should be supplying all DBFs,
SAXParserFactory's, and TransformerFactory's available in the system,
I suggest that XMLUtil be given a few new methods to search through
factories looking for impls that supply given abstract capabilities:
support for DOM Events would be one example. Furthermore, autoload
modules providing such XML-related factories could be marked with
OpenIDE-Module-Provides, so that client modules could just declare e.g.:

OpenIDE-Module-Requires: javax.xml.parsers.DocumentBuilderFactory,


DocumentBuilderFactory f =
XMLUtil.findDocumentBuilderFactory(XMLUtil.WITH_DOM_EVENTS |
// f should be non-null because we depended on these features

Look attractive?
Comment 24 David Konecny 2003-02-28 13:06:53 UTC
I looked as this task and would prefer to leave it on Dusan.
Comment 25 Jesse Glick 2003-12-19 15:13:44 UTC
In trunk, still looks up Xerces' DocumentBuilderFactoryImpl by
Class.forName (so as to guarantee DOM Event support), and uses
serializers package.