You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Craeg K Strong <cs...@arielpartners.com> on 2002/05/27 22:05:35 UTC

xmlParserAPIs.jar vs xml-apis.jar

Hello:

What a mess!   Who knows if those two classes are important or not...

Of course, all of the Ant tests run without them (I removed xmlParserAPIs.jar
and everything ran find on both Win32 and Linux with xml-apis.jar)

but who knows what 3rd party code would break in unexpected ways if we didn't 
include them. >:-(

Perhaps the Xalan people would give us a more up to date xml-apis.jar that
includes those two classes?  Then we could avoid bundling xmlParserAPIs.jar

Also, I like the idea of xalan.jar in lib/optional   As you say, it is not
required, but isn't that the point of the optional directory?

You include junit.jar if you want to run the tests
You include xalan.jar if you want to run the Xslt tests or use <xslt>

While it is not required, it would be a virtuous thing to do, especially since
it would be a version that is guaranteed to work with the bundled version
of xml-apis.jar    It would therefore probably prevent lots of support 
questions/emails/spurious bug reports.  Ne c'est pas?

--Craeg

 >> [PROPOSAL]

 >> What about this as an alternative:

 >> 1) replace xmlParserAPIs.jar with xml-apis.jar in lib/
 >> 2) put xalan.jar in lib/optional
 >> 3) apply the attached patches to bootstrap.bat, bootstrap.sh,
 >>   build.sh, build.bat, and build.xml

 >> xml-apis.jar seems to be a strict superset of xmlParserAPIs.jar
 >> That is, it is the same except that it includes the entire JAXP
 >> rather than xerces' chopped down version.

 > I agree that (1) would be the simplest fix but I did a quick check with the >
 > latest xalan xml-apis.jar and the xerces xmlParserAPIs.jar in Ant's CVS and  \
 > found two classes which are not in xml-apis.jar

 > Only in temp2/org/xml/sax/helpers: NewInstance.class
 > Only in temp2/org/w3c/dom/html: HTMLDOMImplementation.class

 > So, it is not a strict superset.

 > Not sure that (2) is required


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: xmlParserAPIs.jar vs xml-apis.jar

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 27 May 2002, Craeg K. Strong <cs...@arielpartners.com>
wrote:

> Perhaps the Xalan people would give us a more up to date
> xml-apis.jar that includes those two classes?

Please let's stick with released version of jars so that we can tell
people this is xml-apis.jar from Xalan-J 2.3.1 etc.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: xmlParserAPIs.jar vs xml-apis.jar

Posted by co...@covalent.net.
AFAIK, the xml-commons/java/external is the 'official' apache repository
for xml apis ( JAXP, DOM, SAX ). 

I remember for 'updates' or bug fixes to the SAX spec ( after 2.0),
and same thing may happened on DOM - the goal is to keep the 
repository in sync with the standard body.

The differences in the .jar files are most likely due to different
release dates. AFAIK all changes in DOM and SAX are backward compatible,
and the new API should work with older implementations without 
problems.

( xml-apis.jar is no different than ant.jar - backward compatibility is a 
goal but usually you're safer with the latest version ).

You should also keep in mind that JDK1.4 has its own version of 
SAX, DOM, JAXP and it is probably not updated with the latest
fixes. Again, AFAIK both xalan and xerces are aware of this and
their code should compile and work with JDK1.4. 

For those using SAXON - AFAIK saxon also implements the JAXP 
specs, so using it shouldn't be a problem. Having an explicit
attribute to point to the parser/xslt implementation in all
tasks that deal with XML would allow the user to explicitely
chose.

Costin


On Mon, 27 May 2002, Craeg K Strong wrote:

> Hello:
> 
> What a mess!   Who knows if those two classes are important or not...
> 
> Of course, all of the Ant tests run without them (I removed xmlParserAPIs.jar
> and everything ran find on both Win32 and Linux with xml-apis.jar)
> 
> but who knows what 3rd party code would break in unexpected ways if we didn't 
> include them. >:-(
> 
> Perhaps the Xalan people would give us a more up to date xml-apis.jar that
> includes those two classes?  Then we could avoid bundling xmlParserAPIs.jar
> 
> Also, I like the idea of xalan.jar in lib/optional   As you say, it is not
> required, but isn't that the point of the optional directory?
> 
> You include junit.jar if you want to run the tests
> You include xalan.jar if you want to run the Xslt tests or use <xslt>
> 
> While it is not required, it would be a virtuous thing to do, especially since
> it would be a version that is guaranteed to work with the bundled version
> of xml-apis.jar    It would therefore probably prevent lots of support 
> questions/emails/spurious bug reports.  Ne c'est pas?
> 
> --Craeg
> 
>  >> [PROPOSAL]
> 
>  >> What about this as an alternative:
> 
>  >> 1) replace xmlParserAPIs.jar with xml-apis.jar in lib/
>  >> 2) put xalan.jar in lib/optional
>  >> 3) apply the attached patches to bootstrap.bat, bootstrap.sh,
>  >>   build.sh, build.bat, and build.xml
> 
>  >> xml-apis.jar seems to be a strict superset of xmlParserAPIs.jar
>  >> That is, it is the same except that it includes the entire JAXP
>  >> rather than xerces' chopped down version.
> 
>  > I agree that (1) would be the simplest fix but I did a quick check with the >
>  > latest xalan xml-apis.jar and the xerces xmlParserAPIs.jar in Ant's CVS and  \
>  > found two classes which are not in xml-apis.jar
> 
>  > Only in temp2/org/xml/sax/helpers: NewInstance.class
>  > Only in temp2/org/w3c/dom/html: HTMLDOMImplementation.class
> 
>  > So, it is not a strict superset.
> 
>  > Not sure that (2) is required
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>