You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xerces.apache.org by Scott Boag/CAM/Lotus <Sc...@lotus.com> on 2000/04/20 21:24:13 UTC
Re: Build questions
Hmmm... when I search for NodeBase.java the only place I find it is in my
copy of James Clark's XT!. Was NodeBase added recently to Xerces. Anyone
on the Xerces side of the fence know what's going on? I'm confused...
-scott
Eric Hodges
<harmony2@swb To: xalan-dev@xml.apache.org
ell.net> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Build questions
04/20/2000
03:01 PM
Please
respond to
xalan-dev
I'm having some trouble with my current installation of Xalan and Xerces,
so I decided to get the latest and greatest from www.apache.org. The
org.w3c.dom package that comes with these conflicts with the one used by
the current release of JAXP (1.0). Methods like normalize() are in
NodeBase.java in the Apache version of org.w3c.dom, but not in the one used
by Sun. Does anyone know how to get JAXP and Xalan to play nice?
Re: Build questions
Posted by Rajiv Mordani <Ra...@eng.sun.com>.
Yes the code under whiteboard does derive from Crimson and does have the
DOM Level 2, though not fully implemented as pointed out by Ed.
- Rajiv
--
:wq
On Fri, 21 Apr 2000, Edwin Goei wrote:
> Arnaud Le Hors wrote:
> >
> > NodeBase is a class part of Crimson and can be found in the experimental
> > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > It is neither part of Xerces nor the W3C DOM package.
>
> I haven't looked at the code under
> /xml-xerces/java/src/whiteboard/org/apache/tree but I am told it is
> derived from /xml-contrib/crimson/* which I am familiar with. The
> crimson code does implement the DOM2 interfaces (not fully conformant
> though). Rajiv would be the person to ask as to what is under the
> whiteboard directory.
>
Re: Build questions
Posted by Rajiv Mordani <Ra...@eng.sun.com>.
Yes the code under whiteboard does derive from Crimson and does have the
DOM Level 2, though not fully implemented as pointed out by Ed.
- Rajiv
--
:wq
On Fri, 21 Apr 2000, Edwin Goei wrote:
> Arnaud Le Hors wrote:
> >
> > NodeBase is a class part of Crimson and can be found in the experimental
> > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > It is neither part of Xerces nor the W3C DOM package.
>
> I haven't looked at the code under
> /xml-xerces/java/src/whiteboard/org/apache/tree but I am told it is
> derived from /xml-contrib/crimson/* which I am familiar with. The
> crimson code does implement the DOM2 interfaces (not fully conformant
> though). Rajiv would be the person to ask as to what is under the
> whiteboard directory.
>
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Arnaud Le Hors wrote:
>
> NodeBase is a class part of Crimson and can be found in the experimental
> directory xml-xerces/java/src/whiteboard/org/apache/tree
> It is neither part of Xerces nor the W3C DOM package.
I haven't looked at the code under
/xml-xerces/java/src/whiteboard/org/apache/tree but I am told it is
derived from /xml-contrib/crimson/* which I am familiar with. The
crimson code does implement the DOM2 interfaces (not fully conformant
though). Rajiv would be the person to ask as to what is under the
whiteboard directory.
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Arnaud Le Hors wrote:
>
> NodeBase is a class part of Crimson and can be found in the experimental
> directory xml-xerces/java/src/whiteboard/org/apache/tree
> It is neither part of Xerces nor the W3C DOM package.
I haven't looked at the code under
/xml-xerces/java/src/whiteboard/org/apache/tree but I am told it is
derived from /xml-contrib/crimson/* which I am familiar with. The
crimson code does implement the DOM2 interfaces (not fully conformant
though). Rajiv would be the person to ask as to what is under the
whiteboard directory.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
I downloaded WinCVS. 1.1 beta wouldn't run. 1.0.6 runs, but I have no idea
how to get at the source. Where do I browse the files on the host? I've
tried checkout and import, but they all seem to want me to type in a path to
a specific file. I don't see a way to get all the crimson source code.
----- Original Message -----
From: "Edwin Goei" <Ed...@eng.sun.com>
To: <xa...@xml.apache.org>
Sent: Friday, April 21, 2000 8:28 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > ----- Original Message -----
> > From: "Edwin Goei" <Ed...@eng.sun.com>
> > To: <xa...@xml.apache.org>
> > Cc: <xe...@xml.apache.org>
> > Sent: Friday, April 21, 2000 4:42 PM
> > Subject: Re: Build questions
> >
> > > Eric Hodges wrote:
> > > > Where do I see that? The source I downloaded for xerces 1.0.3
doesn't
> > have
> > > > any JAXP stuf in it.
> > >
> > > It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> > > CVS tree and build it yourself to get a jar file with the JAXP classes
> > > in them.
> >
> > I assume I'll need some sort of CVS client and access to some server?
> > Bummer. I guess I'll start learning CVS now.
>
> See http://xml.apache.org/cvs.html.
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Eric Hodges wrote:
>
> ----- Original Message -----
> From: "Edwin Goei" <Ed...@eng.sun.com>
> To: <xa...@xml.apache.org>
> Cc: <xe...@xml.apache.org>
> Sent: Friday, April 21, 2000 4:42 PM
> Subject: Re: Build questions
>
> > Eric Hodges wrote:
> > > Where do I see that? The source I downloaded for xerces 1.0.3 doesn't
> have
> > > any JAXP stuf in it.
> >
> > It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> > CVS tree and build it yourself to get a jar file with the JAXP classes
> > in them.
>
> I assume I'll need some sort of CVS client and access to some server?
> Bummer. I guess I'll start learning CVS now.
See http://xml.apache.org/cvs.html.
Re: Build questions
Posted by Rajiv Mordani <Ra...@eng.sun.com>.
I think till the license issue gets fixed we should just use the jaxp.jar
from the RI (see my earlier posting regarding this). The implementation is
available from Pier already. So not a problem.
- Rajiv
--
:wq
On Mon, 24 Apr 2000, Mike Pogue wrote:
> Or, just get the daily tarball, from http://xml.apache.org/from-cvs .
> No anon cvs required!
>
> NOTE: The JAXP stuff is still in an ambiguous legal state. It's not
> clear that we have the rights yet to use and distribute it (see the JAXP
> license spec, for details). Sun is working to fix this. In the mean time,
> you have been warned! :-)
>
> Mike
>
> Eric Hodges wrote:
> >
> > ----- Original Message -----
> > From: "Edwin Goei" <Ed...@eng.sun.com>
> > To: <xa...@xml.apache.org>
> > Cc: <xe...@xml.apache.org>
> > Sent: Friday, April 21, 2000 4:42 PM
> > Subject: Re: Build questions
> >
> > > Eric Hodges wrote:
> > > > Where do I see that? The source I downloaded for xerces 1.0.3 doesn't
> > have
> > > > any JAXP stuf in it.
> > >
> > > It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> > > CVS tree and build it yourself to get a jar file with the JAXP classes
> > > in them.
> >
> > I assume I'll need some sort of CVS client and access to some server?
> > Bummer. I guess I'll start learning CVS now.
>
Re: Build questions
Posted by Mike Pogue <mp...@apache.org>.
Or, just get the daily tarball, from http://xml.apache.org/from-cvs .
No anon cvs required!
NOTE: The JAXP stuff is still in an ambiguous legal state. It's not
clear that we have the rights yet to use and distribute it (see the JAXP
license spec, for details). Sun is working to fix this. In the mean time,
you have been warned! :-)
Mike
Eric Hodges wrote:
>
> ----- Original Message -----
> From: "Edwin Goei" <Ed...@eng.sun.com>
> To: <xa...@xml.apache.org>
> Cc: <xe...@xml.apache.org>
> Sent: Friday, April 21, 2000 4:42 PM
> Subject: Re: Build questions
>
> > Eric Hodges wrote:
> > > Where do I see that? The source I downloaded for xerces 1.0.3 doesn't
> have
> > > any JAXP stuf in it.
> >
> > It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> > CVS tree and build it yourself to get a jar file with the JAXP classes
> > in them.
>
> I assume I'll need some sort of CVS client and access to some server?
> Bummer. I guess I'll start learning CVS now.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Edwin Goei" <Ed...@eng.sun.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Friday, April 21, 2000 4:42 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> > Where do I see that? The source I downloaded for xerces 1.0.3 doesn't
have
> > any JAXP stuf in it.
>
> It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> CVS tree and build it yourself to get a jar file with the JAXP classes
> in them.
I assume I'll need some sort of CVS client and access to some server?
Bummer. I guess I'll start learning CVS now.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Edwin Goei" <Ed...@eng.sun.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Friday, April 21, 2000 4:42 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> > Where do I see that? The source I downloaded for xerces 1.0.3 doesn't
have
> > any JAXP stuf in it.
>
> It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
> CVS tree and build it yourself to get a jar file with the JAXP classes
> in them.
I assume I'll need some sort of CVS client and access to some server?
Bummer. I guess I'll start learning CVS now.
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Eric Hodges wrote:
>
> > My guess is that you want
> > to use the parser independent JAXP interfaces to create a DOM tree and
> > that you are trying to use the JAXP FCS reference implementation (RI)
> > with Xalan and Xalan has a dependency on the DOM2 interfaces while the
> > JAXP RI depends on DOM1 interfaces.
>
> Yes.
>
> >
> > If this is correct, then why not use the JAXP interfaces for Xerces? I
> > am told that you need to build Xerces to get these. See
> > /xml-xerces/java/src/javax/xml/*.
>
> Where do I see that? The source I downloaded for xerces 1.0.3 doesn't have
> any JAXP stuf in it.
It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
CVS tree and build it yourself to get a jar file with the JAXP classes
in them.
> > Alternatively, if you want to use
> > JAXP RI based parser code, you can build the crimson code which does
> > implement DOM level 2 methods.
>
> And what is the "crimson code"?
The JAXP RI which is based on Sun's parser was donated to Apache under
the name "Crimson". You can find it at /xml-contrib/crimson/*. See my
other posting on this subject.
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Eric Hodges wrote:
>
> > My guess is that you want
> > to use the parser independent JAXP interfaces to create a DOM tree and
> > that you are trying to use the JAXP FCS reference implementation (RI)
> > with Xalan and Xalan has a dependency on the DOM2 interfaces while the
> > JAXP RI depends on DOM1 interfaces.
>
> Yes.
>
> >
> > If this is correct, then why not use the JAXP interfaces for Xerces? I
> > am told that you need to build Xerces to get these. See
> > /xml-xerces/java/src/javax/xml/*.
>
> Where do I see that? The source I downloaded for xerces 1.0.3 doesn't have
> any JAXP stuf in it.
It is not part of the xerces 1.0.3 jar file, you need to get a Xerces
CVS tree and build it yourself to get a jar file with the JAXP classes
in them.
> > Alternatively, if you want to use
> > JAXP RI based parser code, you can build the crimson code which does
> > implement DOM level 2 methods.
>
> And what is the "crimson code"?
The JAXP RI which is based on Sun's parser was donated to Apache under
the name "Crimson". You can find it at /xml-contrib/crimson/*. See my
other posting on this subject.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Edwin Goei <Ed...@eng.sun.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Friday, April 21, 2000 11:26 AM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > ----- Original Message -----
> > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Thursday, April 20, 2000 7:32 PM
> > Subject: Re: Build questions
> >
> > > NodeBase is a class part of Crimson and can be found in the
experimental
> > > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > > It is neither part of Xerces nor the W3C DOM package.
> >
> > NodeBase is also a class in Sun's JAXP implementation. The problem is
that
> > com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
> > implements is from DOM 1, so it doesn't implement normalize(). If I use
the
> > org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become
abstract.
> > If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't
build.
>
> I'm not quite sure what you're trying to do.
What I'm trying to do:
I want to use JAXP for my parser interface. I don't care which
implementation. I need a standard interface to this stuff.
I want to use Xalan for XSLT processing. The Documents that come from JAXP
are fed into Xalan's stuff. A standard interface would be great, but I
can't find one.
> My guess is that you want
> to use the parser independent JAXP interfaces to create a DOM tree and
> that you are trying to use the JAXP FCS reference implementation (RI)
> with Xalan and Xalan has a dependency on the DOM2 interfaces while the
> JAXP RI depends on DOM1 interfaces.
Yes.
>
> If this is correct, then why not use the JAXP interfaces for Xerces? I
> am told that you need to build Xerces to get these. See
> /xml-xerces/java/src/javax/xml/*.
Where do I see that? The source I downloaded for xerces 1.0.3 doesn't have
any JAXP stuf in it.
> Alternatively, if you want to use
> JAXP RI based parser code, you can build the crimson code which does
> implement DOM level 2 methods.
And what is the "crimson code"?
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Edwin Goei <Ed...@eng.sun.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Friday, April 21, 2000 11:26 AM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > ----- Original Message -----
> > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Thursday, April 20, 2000 7:32 PM
> > Subject: Re: Build questions
> >
> > > NodeBase is a class part of Crimson and can be found in the
experimental
> > > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > > It is neither part of Xerces nor the W3C DOM package.
> >
> > NodeBase is also a class in Sun's JAXP implementation. The problem is
that
> > com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
> > implements is from DOM 1, so it doesn't implement normalize(). If I use
the
> > org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become
abstract.
> > If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't
build.
>
> I'm not quite sure what you're trying to do.
What I'm trying to do:
I want to use JAXP for my parser interface. I don't care which
implementation. I need a standard interface to this stuff.
I want to use Xalan for XSLT processing. The Documents that come from JAXP
are fed into Xalan's stuff. A standard interface would be great, but I
can't find one.
> My guess is that you want
> to use the parser independent JAXP interfaces to create a DOM tree and
> that you are trying to use the JAXP FCS reference implementation (RI)
> with Xalan and Xalan has a dependency on the DOM2 interfaces while the
> JAXP RI depends on DOM1 interfaces.
Yes.
>
> If this is correct, then why not use the JAXP interfaces for Xerces? I
> am told that you need to build Xerces to get these. See
> /xml-xerces/java/src/javax/xml/*.
Where do I see that? The source I downloaded for xerces 1.0.3 doesn't have
any JAXP stuf in it.
> Alternatively, if you want to use
> JAXP RI based parser code, you can build the crimson code which does
> implement DOM level 2 methods.
And what is the "crimson code"?
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Eric Hodges wrote:
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Thursday, April 20, 2000 7:32 PM
> Subject: Re: Build questions
>
> > NodeBase is a class part of Crimson and can be found in the experimental
> > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > It is neither part of Xerces nor the W3C DOM package.
>
> NodeBase is also a class in Sun's JAXP implementation. The problem is that
> com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
> implements is from DOM 1, so it doesn't implement normalize(). If I use the
> org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become abstract.
> If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't build.
I'm not quite sure what you're trying to do. My guess is that you want
to use the parser independent JAXP interfaces to create a DOM tree and
that you are trying to use the JAXP FCS reference implementation (RI)
with Xalan and Xalan has a dependency on the DOM2 interfaces while the
JAXP RI depends on DOM1 interfaces.
If this is correct, then why not use the JAXP interfaces for Xerces? I
am told that you need to build Xerces to get these. See
/xml-xerces/java/src/javax/xml/*. Alternatively, if you want to use
JAXP RI based parser code, you can build the crimson code which does
implement DOM level 2 methods.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Then there should be 2 separate implementations. They can delegate to
common helper classes when possible, but emphasis should be on ease of use,
not ease of implementation.
The current solution makes it impossible to mix components that depend on
different versions of the same package. So if I wrote a component that uses
org.w3c.dom from one day before the DOM 2 support was added, it can't work
with a component written the next day.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Monday, April 24, 2000 4:22 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > I see. Then I think they should have made an entirely new package for
DOM 2
> > that shares no dependencies with DOM 1.
>
> Although this would work for applications it would be impossible for an
> implementation to implement both packages with the same classes; because
> you end up with similar methods with a different return type. Major
> bummer!
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Then there should be 2 separate implementations. They can delegate to
common helper classes when possible, but emphasis should be on ease of use,
not ease of implementation.
The current solution makes it impossible to mix components that depend on
different versions of the same package. So if I wrote a component that uses
org.w3c.dom from one day before the DOM 2 support was added, it can't work
with a component written the next day.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Monday, April 24, 2000 4:22 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > I see. Then I think they should have made an entirely new package for
DOM 2
> > that shares no dependencies with DOM 1.
>
> Although this would work for applications it would be impossible for an
> implementation to implement both packages with the same classes; because
> you end up with similar methods with a different return type. Major
> bummer!
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> I see. Then I think they should have made an entirely new package for DOM 2
> that shares no dependencies with DOM 1.
Although this would work for applications it would be impossible for an
implementation to implement both packages with the same classes; because
you end up with similar methods with a different return type. Major
bummer!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
Eric Hodges wrote:
>
> What's ProjectX?
Crimson.
Just make sure you don't have any parser.jar, projectx.jar or any other
DOM L1-containing JAR in your classpath when you build Xerces or Xalan.
That should include whatever the IDE accepts as the classpath and the
JDK lib/ext directory.
arkin
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
Eric Hodges wrote:
>
> What's ProjectX?
Crimson.
Just make sure you don't have any parser.jar, projectx.jar or any other
DOM L1-containing JAR in your classpath when you build Xerces or Xalan.
That should include whatever the IDE accepts as the classpath and the
JDK lib/ext directory.
arkin
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
What's ProjectX?
----- Original Message -----
From: Arkin <ar...@exoffice.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:36 PM
Subject: Re: Build questions
> ZIP? Or are you trying to build Xerces with ProjectX in the classpath?
>
> arkin
>
>
> Eric Hodges wrote:
> >
> > I don't have any jars. The real problem seems to be that Xalan and
Xerces
> > depend on the features found in the new org.w3c.dom, and JAXP just
doesn't
> > support them.
> >
> > ----- Original Message -----
> > From: Arkin <ar...@exoffice.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Tuesday, April 25, 2000 5:14 PM
> > Subject: Re: Build questions
> >
> > > Solution 1: You put the JAR with the DOM Level 2 interfaces first in
the
> > > classpath and cross your fingers.
> > >
> > > Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> > > WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
> > >
> > > I recommend solution no. 2.
> > >
> > > arkin
> > >
> > > Eric Hodges wrote:
> > > >
> > > > How so? And how do you load the DOM level 2 interface "first"?
> > > >
> > > > ----- Original Message -----
> > > > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > > > To: <xe...@xml.apache.org>
> > > > Cc: <xa...@xml.apache.org>
> > > > Sent: Monday, April 24, 2000 4:24 PM
> > > > Subject: Re: Build questions
> > > >
> > > > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > > > interfaces first, everything should work just fine!
> > > > > --
> > > > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > Assaf Arkin www.exoffice.com
> > > CTO, Exoffice Technologies, Inc. www.exolab.org
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
What's ProjectX?
----- Original Message -----
From: Arkin <ar...@exoffice.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:36 PM
Subject: Re: Build questions
> ZIP? Or are you trying to build Xerces with ProjectX in the classpath?
>
> arkin
>
>
> Eric Hodges wrote:
> >
> > I don't have any jars. The real problem seems to be that Xalan and
Xerces
> > depend on the features found in the new org.w3c.dom, and JAXP just
doesn't
> > support them.
> >
> > ----- Original Message -----
> > From: Arkin <ar...@exoffice.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Tuesday, April 25, 2000 5:14 PM
> > Subject: Re: Build questions
> >
> > > Solution 1: You put the JAR with the DOM Level 2 interfaces first in
the
> > > classpath and cross your fingers.
> > >
> > > Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> > > WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
> > >
> > > I recommend solution no. 2.
> > >
> > > arkin
> > >
> > > Eric Hodges wrote:
> > > >
> > > > How so? And how do you load the DOM level 2 interface "first"?
> > > >
> > > > ----- Original Message -----
> > > > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > > > To: <xe...@xml.apache.org>
> > > > Cc: <xa...@xml.apache.org>
> > > > Sent: Monday, April 24, 2000 4:24 PM
> > > > Subject: Re: Build questions
> > > >
> > > > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > > > interfaces first, everything should work just fine!
> > > > > --
> > > > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > Assaf Arkin www.exoffice.com
> > > CTO, Exoffice Technologies, Inc. www.exolab.org
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
ZIP? Or are you trying to build Xerces with ProjectX in the classpath?
arkin
Eric Hodges wrote:
>
> I don't have any jars. The real problem seems to be that Xalan and Xerces
> depend on the features found in the new org.w3c.dom, and JAXP just doesn't
> support them.
>
> ----- Original Message -----
> From: Arkin <ar...@exoffice.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Tuesday, April 25, 2000 5:14 PM
> Subject: Re: Build questions
>
> > Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
> > classpath and cross your fingers.
> >
> > Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> > WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
> >
> > I recommend solution no. 2.
> >
> > arkin
> >
> > Eric Hodges wrote:
> > >
> > > How so? And how do you load the DOM level 2 interface "first"?
> > >
> > > ----- Original Message -----
> > > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > > To: <xe...@xml.apache.org>
> > > Cc: <xa...@xml.apache.org>
> > > Sent: Monday, April 24, 2000 4:24 PM
> > > Subject: Re: Build questions
> > >
> > > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > > interfaces first, everything should work just fine!
> > > > --
> > > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
ZIP? Or are you trying to build Xerces with ProjectX in the classpath?
arkin
Eric Hodges wrote:
>
> I don't have any jars. The real problem seems to be that Xalan and Xerces
> depend on the features found in the new org.w3c.dom, and JAXP just doesn't
> support them.
>
> ----- Original Message -----
> From: Arkin <ar...@exoffice.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Tuesday, April 25, 2000 5:14 PM
> Subject: Re: Build questions
>
> > Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
> > classpath and cross your fingers.
> >
> > Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> > WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
> >
> > I recommend solution no. 2.
> >
> > arkin
> >
> > Eric Hodges wrote:
> > >
> > > How so? And how do you load the DOM level 2 interface "first"?
> > >
> > > ----- Original Message -----
> > > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > > To: <xe...@xml.apache.org>
> > > Cc: <xa...@xml.apache.org>
> > > Sent: Monday, April 24, 2000 4:24 PM
> > > Subject: Re: Build questions
> > >
> > > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > > interfaces first, everything should work just fine!
> > > > --
> > > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
I don't have any jars. The real problem seems to be that Xalan and Xerces
depend on the features found in the new org.w3c.dom, and JAXP just doesn't
support them.
----- Original Message -----
From: Arkin <ar...@exoffice.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:14 PM
Subject: Re: Build questions
> Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
> classpath and cross your fingers.
>
> Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
>
> I recommend solution no. 2.
>
> arkin
>
> Eric Hodges wrote:
> >
> > How so? And how do you load the DOM level 2 interface "first"?
> >
> > ----- Original Message -----
> > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Monday, April 24, 2000 4:24 PM
> > Subject: Re: Build questions
> >
> > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > interfaces first, everything should work just fine!
> > > --
> > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
I don't have any jars. The real problem seems to be that Xalan and Xerces
depend on the features found in the new org.w3c.dom, and JAXP just doesn't
support them.
----- Original Message -----
From: Arkin <ar...@exoffice.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:14 PM
Subject: Re: Build questions
> Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
> classpath and cross your fingers.
>
> Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
> WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
>
> I recommend solution no. 2.
>
> arkin
>
> Eric Hodges wrote:
> >
> > How so? And how do you load the DOM level 2 interface "first"?
> >
> > ----- Original Message -----
> > From: "Arnaud Le Hors" <le...@us.ibm.com>
> > To: <xe...@xml.apache.org>
> > Cc: <xa...@xml.apache.org>
> > Sent: Monday, April 24, 2000 4:24 PM
> > Subject: Re: Build questions
> >
> > > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > > interfaces first, everything should work just fine!
> > > --
> > > Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
classpath and cross your fingers.
Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
I recommend solution no. 2.
arkin
Eric Hodges wrote:
>
> How so? And how do you load the DOM level 2 interface "first"?
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Monday, April 24, 2000 4:24 PM
> Subject: Re: Build questions
>
> > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > interfaces first, everything should work just fine!
> > --
> > Arnaud Le Hors - IBM Cupertino, XML Technology Group
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Arkin <ar...@exoffice.com>.
Solution 1: You put the JAR with the DOM Level 2 interfaces first in the
classpath and cross your fingers.
Solution 2: You open up the JAR with the DOM Level 1 interfaces (use
WinZip or Emacs) and delete all the DOM Level 1 interfaces from it.
I recommend solution no. 2.
arkin
Eric Hodges wrote:
>
> How so? And how do you load the DOM level 2 interface "first"?
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Monday, April 24, 2000 4:24 PM
> Subject: Re: Build questions
>
> > Note that in Java 1.2, if you make sure you load the DOM Level 2
> > interfaces first, everything should work just fine!
> > --
> > Arnaud Le Hors - IBM Cupertino, XML Technology Group
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
So basically I'm SOL on Xerces and Xalan until Sun releases a new JAXP?
That's sad. So what are other people using if not JAXP? Just hard coding
against Apache?
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 3:45 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > Very interesting, I had no idea Java 2 did this.
> >
> > The problem is that (I'm pretty sure) Xalan and Xerces call the
> > unimplemented methods in my Document.
>
> This problem would exist no matter how the DOM interfaces evolve. You'll
> always need to use an implementation that is at the minimum at the
> highest level the modules you use require.
>
>
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
So basically I'm SOL on Xerces and Xalan until Sun releases a new JAXP?
That's sad. So what are other people using if not JAXP? Just hard coding
against Apache?
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 3:45 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > Very interesting, I had no idea Java 2 did this.
> >
> > The problem is that (I'm pretty sure) Xalan and Xerces call the
> > unimplemented methods in my Document.
>
> This problem would exist no matter how the DOM interfaces evolve. You'll
> always need to use an implementation that is at the minimum at the
> highest level the modules you use require.
>
>
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> Very interesting, I had no idea Java 2 did this.
>
> The problem is that (I'm pretty sure) Xalan and Xerces call the
> unimplemented methods in my Document.
This problem would exist no matter how the DOM interfaces evolve. You'll
always need to use an implementation that is at the minimum at the
highest level the modules you use require.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 6:19 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> >
> > We build the source. We tried to use the jars, but we found ourselves
> > stepping in to source a lot to find out how to use things.
>
> Having the code around to look into it and making part of your source
> are two very different things. While I understand the former, I don't
> understand the latter. And given the problem you're now facing I would
> advise you to reconsider this.
OK, I've created a jar for JAXP (against the old org.w3c.dom, but it doesn't
include it) and am trying to use this jar and the Xalan and Xerces jars.
When I go to compile my project, I get a fatal error saying that
com.sun.xml.tree.ElementNode must be recompiled because
org.w3c.dom.Element.normalize has changed. Only it can't recompiled it
because all it has is the class in the JAXP jar. I tried JDK 1.2 and JDK
1.2.2 with the same results.
com.sun.xml.tree.ElementNode has a normalize() method in it with the same
signature as the one in org.w3c.dom.Node. Any tips?
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 6:19 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> >
> > We build the source. We tried to use the jars, but we found ourselves
> > stepping in to source a lot to find out how to use things.
>
> Having the code around to look into it and making part of your source
> are two very different things. While I understand the former, I don't
> understand the latter. And given the problem you're now facing I would
> advise you to reconsider this.
OK, I've created a jar for JAXP (against the old org.w3c.dom, but it doesn't
include it) and am trying to use this jar and the Xalan and Xerces jars.
When I go to compile my project, I get a fatal error saying that
com.sun.xml.tree.ElementNode must be recompiled because
org.w3c.dom.Element.normalize has changed. Only it can't recompiled it
because all it has is the class in the JAXP jar. I tried JDK 1.2 and JDK
1.2.2 with the same results.
com.sun.xml.tree.ElementNode has a normalize() method in it with the same
signature as the one in org.w3c.dom.Node. Any tips?
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
>
> We build the source. We tried to use the jars, but we found ourselves
> stepping in to source a lot to find out how to use things.
Having the code around to look into it and making part of your source
are two very different things. While I understand the former, I don't
understand the latter. And given the problem you're now facing I would
advise you to reconsider this.
> > We don't currently do it actually. But yes, that's how I'd do it. I'd
> > have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
> > the relevant part of the build.
>
> Ah. See, to me, that's nightmarish.
Ok, so we disagree on what is nightmarish. Although I agree it's not
ideal I find that very easy to deal with (assuming the use of
makefiles).
> I don't want to double the complexity
> of our build because of this.
Not rehashing the complexity aspect of this, which clearly is
subjective, I would, again, advise you to avoid this altogether by
simply using the jars!
> And anyway, it sounds like it just plain
> won't work, regardless of how we build it.
Well, I guarantee you it would work. Although I haven't done it for the
full DOM, I've tried it in a very minimal version of it. It works!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
>
> We build the source. We tried to use the jars, but we found ourselves
> stepping in to source a lot to find out how to use things.
Having the code around to look into it and making part of your source
are two very different things. While I understand the former, I don't
understand the latter. And given the problem you're now facing I would
advise you to reconsider this.
> > We don't currently do it actually. But yes, that's how I'd do it. I'd
> > have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
> > the relevant part of the build.
>
> Ah. See, to me, that's nightmarish.
Ok, so we disagree on what is nightmarish. Although I agree it's not
ideal I find that very easy to deal with (assuming the use of
makefiles).
> I don't want to double the complexity
> of our build because of this.
Not rehashing the complexity aspect of this, which clearly is
subjective, I would, again, advise you to avoid this altogether by
simply using the jars!
> And anyway, it sounds like it just plain
> won't work, regardless of how we build it.
Well, I guarantee you it would work. Although I haven't done it for the
full DOM, I've tried it in a very minimal version of it. It works!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:26 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > We don't use make. Perhaps we should. I don't even think we have make
here
> > except on our Linux machine.
>
> There is something I don't understand here. Do you build Xerces yourself
> as part of your build or do you simply use the xerces jar we distribute?
> It seems to me that doing the latter would allow you to avoid the
> problem altogether (assuming you use java 1.2)
We build the source. We tried to use the jars, but we found ourselves
stepping in to source a lot to find out how to use things.
>
> > Do you keep 2 package structures in version control to accomodate the
> > different org.w3c.dom packages? We have one project we fetch from
> > SourceSafe that contains every package. They come out as one tree. As
I
> > imagine it, we'd have to fetch 2 different trees to 2 different
locations,
> > create 2 separate build projects for JAXP and the rest of the world, and
do
> > 2 different builds. Is that how you do it?
>
> We don't currently do it actually. But yes, that's how I'd do it. I'd
> have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
> the relevant part of the build.
Ah. See, to me, that's nightmarish. I don't want to double the complexity
of our build because of this. And anyway, it sounds like it just plain
won't work, regardless of how we build it.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 5:26 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > We don't use make. Perhaps we should. I don't even think we have make
here
> > except on our Linux machine.
>
> There is something I don't understand here. Do you build Xerces yourself
> as part of your build or do you simply use the xerces jar we distribute?
> It seems to me that doing the latter would allow you to avoid the
> problem altogether (assuming you use java 1.2)
We build the source. We tried to use the jars, but we found ourselves
stepping in to source a lot to find out how to use things.
>
> > Do you keep 2 package structures in version control to accomodate the
> > different org.w3c.dom packages? We have one project we fetch from
> > SourceSafe that contains every package. They come out as one tree. As
I
> > imagine it, we'd have to fetch 2 different trees to 2 different
locations,
> > create 2 separate build projects for JAXP and the rest of the world, and
do
> > 2 different builds. Is that how you do it?
>
> We don't currently do it actually. But yes, that's how I'd do it. I'd
> have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
> the relevant part of the build.
Ah. See, to me, that's nightmarish. I don't want to double the complexity
of our build because of this. And anyway, it sounds like it just plain
won't work, regardless of how we build it.
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> We don't use make. Perhaps we should. I don't even think we have make here
> except on our Linux machine.
There is something I don't understand here. Do you build Xerces yourself
as part of your build or do you simply use the xerces jar we distribute?
It seems to me that doing the latter would allow you to avoid the
problem altogether (assuming you use java 1.2)
> Do you keep 2 package structures in version control to accomodate the
> different org.w3c.dom packages? We have one project we fetch from
> SourceSafe that contains every package. They come out as one tree. As I
> imagine it, we'd have to fetch 2 different trees to 2 different locations,
> create 2 separate build projects for JAXP and the rest of the world, and do
> 2 different builds. Is that how you do it?
We don't currently do it actually. But yes, that's how I'd do it. I'd
have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
the relevant part of the build.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> We don't use make. Perhaps we should. I don't even think we have make here
> except on our Linux machine.
There is something I don't understand here. Do you build Xerces yourself
as part of your build or do you simply use the xerces jar we distribute?
It seems to me that doing the latter would allow you to avoid the
problem altogether (assuming you use java 1.2)
> Do you keep 2 package structures in version control to accomodate the
> different org.w3c.dom packages? We have one project we fetch from
> SourceSafe that contains every package. They come out as one tree. As I
> imagine it, we'd have to fetch 2 different trees to 2 different locations,
> create 2 separate build projects for JAXP and the rest of the world, and do
> 2 different builds. Is that how you do it?
We don't currently do it actually. But yes, that's how I'd do it. I'd
have dom1/org/w3c/dom and dom2/org/w3c/dom and use one or the other in
the relevant part of the build.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 4:20 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > I guess IBM doesn't have to worry about
> > using the latest components from Sun and Apache.
>
> We have a whole team working full time on this project so I'm not sure
> what you're trying to say here...
I was commenting on your smiley face in your last message. Sorry if I seem
cross, but I'm spending more time than I would like on somthing that I
thought would just work.
> But, anyway, we just don't have the problem you're mentioning. I'm sorry
> for you your build tool doesn't allow you to specify two different
> classpaths. It's absolutely straight forward to do with make, which is
> what we use (even for automated builds).
We don't use make. Perhaps we should. I don't even think we have make here
except on our Linux machine.
Do you keep 2 package structures in version control to accomodate the
different org.w3c.dom packages? We have one project we fetch from
SourceSafe that contains every package. They come out as one tree. As I
imagine it, we'd have to fetch 2 different trees to 2 different locations,
create 2 separate build projects for JAXP and the rest of the world, and do
2 different builds. Is that how you do it?
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 4:20 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > I guess IBM doesn't have to worry about
> > using the latest components from Sun and Apache.
>
> We have a whole team working full time on this project so I'm not sure
> what you're trying to say here...
I was commenting on your smiley face in your last message. Sorry if I seem
cross, but I'm spending more time than I would like on somthing that I
thought would just work.
> But, anyway, we just don't have the problem you're mentioning. I'm sorry
> for you your build tool doesn't allow you to specify two different
> classpaths. It's absolutely straight forward to do with make, which is
> what we use (even for automated builds).
We don't use make. Perhaps we should. I don't even think we have make here
except on our Linux machine.
Do you keep 2 package structures in version control to accomodate the
different org.w3c.dom packages? We have one project we fetch from
SourceSafe that contains every package. They come out as one tree. As I
imagine it, we'd have to fetch 2 different trees to 2 different locations,
create 2 separate build projects for JAXP and the rest of the world, and do
2 different builds. Is that how you do it?
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> I guess IBM doesn't have to worry about
> using the latest components from Sun and Apache.
We have a whole team working full time on this project so I'm not sure
what you're trying to say here...
But, anyway, we just don't have the problem you're mentioning. I'm sorry
for you your build tool doesn't allow you to specify two different
classpaths. It's absolutely straight forward to do with make, which is
what we use (even for automated builds).
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> I guess IBM doesn't have to worry about
> using the latest components from Sun and Apache.
We have a whole team working full time on this project so I'm not sure
what you're trying to say here...
But, anyway, we just don't have the problem you're mentioning. I'm sorry
for you your build tool doesn't allow you to specify two different
classpaths. It's absolutely straight forward to do with make, which is
what we use (even for automated builds).
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 3:48 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > OK, I'm not even going to try that. The complexity of building against
2
> > versions of the same package is nightmarish.
>
> Nightmarish?? Using two different classpaths in two different parts of
> your code while compiling is trivial.
> But I agree it adds *some* complexity.
Using 2 different classpaths isn't supported by any of our build tools. I
can't ask the rest of the company to abandon automated builds because of
this issue.
>
> > I won't inflict that on the
> > rest of my organization, or the people who use my code.
>
> Fine by me. :-)
Well at least one of us is happy. I guess IBM doesn't have to worry about
using the latest components from Sun and Apache.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: Arnaud Le Hors <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 3:48 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > OK, I'm not even going to try that. The complexity of building against
2
> > versions of the same package is nightmarish.
>
> Nightmarish?? Using two different classpaths in two different parts of
> your code while compiling is trivial.
> But I agree it adds *some* complexity.
Using 2 different classpaths isn't supported by any of our build tools. I
can't ask the rest of the company to abandon automated builds because of
this issue.
>
> > I won't inflict that on the
> > rest of my organization, or the people who use my code.
>
> Fine by me. :-)
Well at least one of us is happy. I guess IBM doesn't have to worry about
using the latest components from Sun and Apache.
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> OK, I'm not even going to try that. The complexity of building against 2
> versions of the same package is nightmarish.
Nightmarish?? Using two different classpaths in two different parts of
your code while compiling is trivial.
But I agree it adds *some* complexity.
> I won't inflict that on the
> rest of my organization, or the people who use my code.
Fine by me. :-)
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> OK, I'm not even going to try that. The complexity of building against 2
> versions of the same package is nightmarish.
Nightmarish?? Using two different classpaths in two different parts of
your code while compiling is trivial.
But I agree it adds *some* complexity.
> I won't inflict that on the
> rest of my organization, or the people who use my code.
Fine by me. :-)
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
OK, I'm not even going to try that. The complexity of building against 2
versions of the same package is nightmarish. I won't inflict that on the
rest of my organization, or the people who use my code.
----- Original Message -----
From: Eric Hodges <ha...@swbell.net>
To: <xa...@xml.apache.org>; <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 1:52 PM
Subject: Re: Build questions
> Very interesting, I had no idea Java 2 did this.
>
> The problem is that (I'm pretty sure) Xalan and Xerces call the
> unimplemented methods in my Document. I'll make sure in about 30 minutes
> when I get to my other system.
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Tuesday, April 25, 2000 1:11 PM
> Subject: Re: Build questions
>
>
> > Eric Hodges wrote:
> > >
> > > How so? And how do you load the DOM level 2 interface "first"?
> >
> > In Java 1.1, at the time the jvm loads the classes it will barf if a
> > class doesn't fully implement the interfaces it claims to implement.
> > This makes it impossible to mix a DOM Level 2 implementation with a DOM
> > Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
> > happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
> > you do not try and use these classes as DOM level 2 classes you're fine.
> > To load the DOM Level 2 interfaces first, all you have to do is to make
> > sure they are in your classpath before the level 1 at runtime.
> >
> > Note that you still need to have the right interfaces at compile time.
> > But this can be accommodated.
> > --
> > Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> Very interesting, I had no idea Java 2 did this.
>
> The problem is that (I'm pretty sure) Xalan and Xerces call the
> unimplemented methods in my Document.
This problem would exist no matter how the DOM interfaces evolve. You'll
always need to use an implementation that is at the minimum at the
highest level the modules you use require.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
OK, I'm not even going to try that. The complexity of building against 2
versions of the same package is nightmarish. I won't inflict that on the
rest of my organization, or the people who use my code.
----- Original Message -----
From: Eric Hodges <ha...@swbell.net>
To: <xa...@xml.apache.org>; <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 1:52 PM
Subject: Re: Build questions
> Very interesting, I had no idea Java 2 did this.
>
> The problem is that (I'm pretty sure) Xalan and Xerces call the
> unimplemented methods in my Document. I'll make sure in about 30 minutes
> when I get to my other system.
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Tuesday, April 25, 2000 1:11 PM
> Subject: Re: Build questions
>
>
> > Eric Hodges wrote:
> > >
> > > How so? And how do you load the DOM level 2 interface "first"?
> >
> > In Java 1.1, at the time the jvm loads the classes it will barf if a
> > class doesn't fully implement the interfaces it claims to implement.
> > This makes it impossible to mix a DOM Level 2 implementation with a DOM
> > Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
> > happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
> > you do not try and use these classes as DOM level 2 classes you're fine.
> > To load the DOM Level 2 interfaces first, all you have to do is to make
> > sure they are in your classpath before the level 1 at runtime.
> >
> > Note that you still need to have the right interfaces at compile time.
> > But this can be accommodated.
> > --
> > Arnaud Le Hors - IBM Cupertino, XML Technology Group
>
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Very interesting, I had no idea Java 2 did this.
The problem is that (I'm pretty sure) Xalan and Xerces call the
unimplemented methods in my Document. I'll make sure in about 30 minutes
when I get to my other system.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 1:11 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > How so? And how do you load the DOM level 2 interface "first"?
>
> In Java 1.1, at the time the jvm loads the classes it will barf if a
> class doesn't fully implement the interfaces it claims to implement.
> This makes it impossible to mix a DOM Level 2 implementation with a DOM
> Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
> happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
> you do not try and use these classes as DOM level 2 classes you're fine.
> To load the DOM Level 2 interfaces first, all you have to do is to make
> sure they are in your classpath before the level 1 at runtime.
>
> Note that you still need to have the right interfaces at compile time.
> But this can be accommodated.
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Very interesting, I had no idea Java 2 did this.
The problem is that (I'm pretty sure) Xalan and Xerces call the
unimplemented methods in my Document. I'll make sure in about 30 minutes
when I get to my other system.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Tuesday, April 25, 2000 1:11 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > How so? And how do you load the DOM level 2 interface "first"?
>
> In Java 1.1, at the time the jvm loads the classes it will barf if a
> class doesn't fully implement the interfaces it claims to implement.
> This makes it impossible to mix a DOM Level 2 implementation with a DOM
> Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
> happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
> you do not try and use these classes as DOM level 2 classes you're fine.
> To load the DOM Level 2 interfaces first, all you have to do is to make
> sure they are in your classpath before the level 1 at runtime.
>
> Note that you still need to have the right interfaces at compile time.
> But this can be accommodated.
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> How so? And how do you load the DOM level 2 interface "first"?
In Java 1.1, at the time the jvm loads the classes it will barf if a
class doesn't fully implement the interfaces it claims to implement.
This makes it impossible to mix a DOM Level 2 implementation with a DOM
Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
you do not try and use these classes as DOM level 2 classes you're fine.
To load the DOM Level 2 interfaces first, all you have to do is to make
sure they are in your classpath before the level 1 at runtime.
Note that you still need to have the right interfaces at compile time.
But this can be accommodated.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> How so? And how do you load the DOM level 2 interface "first"?
In Java 1.1, at the time the jvm loads the classes it will barf if a
class doesn't fully implement the interfaces it claims to implement.
This makes it impossible to mix a DOM Level 2 implementation with a DOM
Level 1 one. On the other hand Java 1.2 doesn't enforce this. It will
happily load DOM level 1 classes with DOM Level 2 interfaces. As long as
you do not try and use these classes as DOM level 2 classes you're fine.
To load the DOM Level 2 interfaces first, all you have to do is to make
sure they are in your classpath before the level 1 at runtime.
Note that you still need to have the right interfaces at compile time.
But this can be accommodated.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
How so? And how do you load the DOM level 2 interface "first"?
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Monday, April 24, 2000 4:24 PM
Subject: Re: Build questions
> Note that in Java 1.2, if you make sure you load the DOM Level 2
> interfaces first, everything should work just fine!
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
How so? And how do you load the DOM level 2 interface "first"?
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Monday, April 24, 2000 4:24 PM
Subject: Re: Build questions
> Note that in Java 1.2, if you make sure you load the DOM Level 2
> interfaces first, everything should work just fine!
> --
> Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Note that in Java 1.2, if you make sure you load the DOM Level 2
interfaces first, everything should work just fine!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Note that in Java 1.2, if you make sure you load the DOM Level 2
interfaces first, everything should work just fine!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> I see. Then I think they should have made an entirely new package for DOM 2
> that shares no dependencies with DOM 1.
Although this would work for applications it would be impossible for an
implementation to implement both packages with the same classes; because
you end up with similar methods with a different return type. Major
bummer!
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Friday, April 21, 2000 6:35 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > <rant>
> > The problem could have been avoided by something like this:
> >
> > package org.w3c.dom2;
> >
> > public interface Node2 extends org.w3c.dom.Node {
> > public void normalize();
> > }
>
> If you look at early drafts of the DOM Level 2 spec you'll see that this
> is what I originally proposed.
Cool.
> But, sometime later, it was decided to
> simply extend DOM Level 1 interfaces. As I recall the main reason was
> that new interfaces would force people to cast objects all over the
> place which would make applications code heavier and have a performance
> cost. This was deemed more important in the long term, than allowing
> different DOM implementations to co-exist.
I see. Then I think they should have made an entirely new package for DOM 2
that shares no dependencies with DOM 1.
> You're entitled to disagree.
Yay.
>
> > Even Microsoft has the decency to freeze their interfaces once they are
> > released.
>
> No comment...
I'm not a Microsoft fan, but working with their COM interfaces is simplified
by the use of interface versions.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Friday, April 21, 2000 6:35 PM
Subject: Re: Build questions
> Eric Hodges wrote:
> >
> > <rant>
> > The problem could have been avoided by something like this:
> >
> > package org.w3c.dom2;
> >
> > public interface Node2 extends org.w3c.dom.Node {
> > public void normalize();
> > }
>
> If you look at early drafts of the DOM Level 2 spec you'll see that this
> is what I originally proposed.
Cool.
> But, sometime later, it was decided to
> simply extend DOM Level 1 interfaces. As I recall the main reason was
> that new interfaces would force people to cast objects all over the
> place which would make applications code heavier and have a performance
> cost. This was deemed more important in the long term, than allowing
> different DOM implementations to co-exist.
I see. Then I think they should have made an entirely new package for DOM 2
that shares no dependencies with DOM 1.
> You're entitled to disagree.
Yay.
>
> > Even Microsoft has the decency to freeze their interfaces once they are
> > released.
>
> No comment...
I'm not a Microsoft fan, but working with their COM interfaces is simplified
by the use of interface versions.
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> <rant>
> The problem could have been avoided by something like this:
>
> package org.w3c.dom2;
>
> public interface Node2 extends org.w3c.dom.Node {
> public void normalize();
> }
If you look at early drafts of the DOM Level 2 spec you'll see that this
is what I originally proposed. But, sometime later, it was decided to
simply extend DOM Level 1 interfaces. As I recall the main reason was
that new interfaces would force people to cast objects all over the
place which would make applications code heavier and have a performance
cost. This was deemed more important in the long term, than allowing
different DOM implementations to co-exist.
You're entitled to disagree.
> Even Microsoft has the decency to freeze their interfaces once they are
> released.
No comment...
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Eric Hodges wrote:
>
> <rant>
> The problem could have been avoided by something like this:
>
> package org.w3c.dom2;
>
> public interface Node2 extends org.w3c.dom.Node {
> public void normalize();
> }
If you look at early drafts of the DOM Level 2 spec you'll see that this
is what I originally proposed. But, sometime later, it was decided to
simply extend DOM Level 1 interfaces. As I recall the main reason was
that new interfaces would force people to cast objects all over the
place which would make applications code heavier and have a performance
cost. This was deemed more important in the long term, than allowing
different DOM implementations to co-exist.
You're entitled to disagree.
> Even Microsoft has the decency to freeze their interfaces once they are
> released.
No comment...
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Edwin Goei <Ed...@eng.sun.com>.
Eric Hodges wrote:
>
> ----- Original Message -----
> From: "Arnaud Le Hors" <le...@us.ibm.com>
> To: <xe...@xml.apache.org>
> Cc: <xa...@xml.apache.org>
> Sent: Thursday, April 20, 2000 7:32 PM
> Subject: Re: Build questions
>
> > NodeBase is a class part of Crimson and can be found in the experimental
> > directory xml-xerces/java/src/whiteboard/org/apache/tree
> > It is neither part of Xerces nor the W3C DOM package.
>
> NodeBase is also a class in Sun's JAXP implementation. The problem is that
> com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
> implements is from DOM 1, so it doesn't implement normalize(). If I use the
> org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become abstract.
> If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't build.
I'm not quite sure what you're trying to do. My guess is that you want
to use the parser independent JAXP interfaces to create a DOM tree and
that you are trying to use the JAXP FCS reference implementation (RI)
with Xalan and Xalan has a dependency on the DOM2 interfaces while the
JAXP RI depends on DOM1 interfaces.
If this is correct, then why not use the JAXP interfaces for Xerces? I
am told that you need to build Xerces to get these. See
/xml-xerces/java/src/javax/xml/*. Alternatively, if you want to use
JAXP RI based parser code, you can build the crimson code which does
implement DOM level 2 methods.
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Thursday, April 20, 2000 7:32 PM
Subject: Re: Build questions
> NodeBase is a class part of Crimson and can be found in the experimental
> directory xml-xerces/java/src/whiteboard/org/apache/tree
> It is neither part of Xerces nor the W3C DOM package.
NodeBase is also a class in Sun's JAXP implementation. The problem is that
com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
implements is from DOM 1, so it doesn't implement normalize(). If I use the
org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become abstract.
If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't build.
<rant>
The problem could have been avoided by something like this:
package org.w3c.dom2;
public interface Node2 extends org.w3c.dom.Node {
public void normalize();
}
Even Microsoft has the decency to freeze their interfaces once they are
released.
</rant>
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
----- Original Message -----
From: "Arnaud Le Hors" <le...@us.ibm.com>
To: <xe...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Thursday, April 20, 2000 7:32 PM
Subject: Re: Build questions
> NodeBase is a class part of Crimson and can be found in the experimental
> directory xml-xerces/java/src/whiteboard/org/apache/tree
> It is neither part of Xerces nor the W3C DOM package.
NodeBase is also a class in Sun's JAXP implementation. The problem is that
com.sun.xml.tree.NodeBase implements org.w3c.dom.Node. The version it
implements is from DOM 1, so it doesn't implement normalize(). If I use the
org.w3c.dom that Xalan and Xerces depend on, JAXP's classes become abstract.
If I use the org.w3c.dom that JAXP depends on, Xalan and Xerces won't build.
<rant>
The problem could have been avoided by something like this:
package org.w3c.dom2;
public interface Node2 extends org.w3c.dom.Node {
public void normalize();
}
Even Microsoft has the decency to freeze their interfaces once they are
released.
</rant>
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
NodeBase is a class part of Crimson and can be found in the experimental
directory xml-xerces/java/src/whiteboard/org/apache/tree
It is neither part of Xerces nor the W3C DOM package.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Arnaud Le Hors <le...@us.ibm.com>.
NodeBase is a class part of Crimson and can be found in the experimental
directory xml-xerces/java/src/whiteboard/org/apache/tree
It is neither part of Xerces nor the W3C DOM package.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Oops, I said NodeBase when I should have said Node.
org.w3c.dom.Node in xerces 1.0.3 has a method normalize().
com.sun.xml.tree.NodeBase from JAXP implements Node, but doesn't implement
the normalize() method.
Apparently normalize() (and some traversal stuff) was added for DOM 2. JAXP
isn't DOM 2 compliant.
Perhaps W3C should have left the DOM 1 interfaces alone and added extension
interfaces for the new features. This would keep it from breaking old code.
----- Original Message -----
From: Scott Boag/CAM/Lotus <Sc...@lotus.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Thursday, April 20, 2000 2:24 PM
Subject: Re: Build questions
>
> Hmmm... when I search for NodeBase.java the only place I find it is in my
> copy of James Clark's XT!. Was NodeBase added recently to Xerces.
Anyone
> on the Xerces side of the fence know what's going on? I'm confused...
>
> -scott
>
>
>
>
>
> Eric Hodges
> <harmony2@swb To: xalan-dev@xml.apache.org
> ell.net> cc: (bcc: Scott
Boag/CAM/Lotus)
> Subject: Build questions
> 04/20/2000
> 03:01 PM
> Please
> respond to
> xalan-dev
>
>
>
>
>
> I'm having some trouble with my current installation of Xalan and Xerces,
> so I decided to get the latest and greatest from www.apache.org. The
> org.w3c.dom package that comes with these conflicts with the one used by
> the current release of JAXP (1.0). Methods like normalize() are in
> NodeBase.java in the Apache version of org.w3c.dom, but not in the one
used
> by Sun. Does anyone know how to get JAXP and Xalan to play nice?
>
>
>
Re: Build questions
Posted by Eric Hodges <ha...@swbell.net>.
Oops, I said NodeBase when I should have said Node.
org.w3c.dom.Node in xerces 1.0.3 has a method normalize().
com.sun.xml.tree.NodeBase from JAXP implements Node, but doesn't implement
the normalize() method.
Apparently normalize() (and some traversal stuff) was added for DOM 2. JAXP
isn't DOM 2 compliant.
Perhaps W3C should have left the DOM 1 interfaces alone and added extension
interfaces for the new features. This would keep it from breaking old code.
----- Original Message -----
From: Scott Boag/CAM/Lotus <Sc...@lotus.com>
To: <xa...@xml.apache.org>
Cc: <xe...@xml.apache.org>
Sent: Thursday, April 20, 2000 2:24 PM
Subject: Re: Build questions
>
> Hmmm... when I search for NodeBase.java the only place I find it is in my
> copy of James Clark's XT!. Was NodeBase added recently to Xerces.
Anyone
> on the Xerces side of the fence know what's going on? I'm confused...
>
> -scott
>
>
>
>
>
> Eric Hodges
> <harmony2@swb To: xalan-dev@xml.apache.org
> ell.net> cc: (bcc: Scott
Boag/CAM/Lotus)
> Subject: Build questions
> 04/20/2000
> 03:01 PM
> Please
> respond to
> xalan-dev
>
>
>
>
>
> I'm having some trouble with my current installation of Xalan and Xerces,
> so I decided to get the latest and greatest from www.apache.org. The
> org.w3c.dom package that comes with these conflicts with the one used by
> the current release of JAXP (1.0). Methods like normalize() are in
> NodeBase.java in the Apache version of org.w3c.dom, but not in the one
used
> by Sun. Does anyone know how to get JAXP and Xalan to play nice?
>
>
>