A SAX-only jar would be feasable, at any rate. I
have built a smaller jar that contains mostly SAX stuff
from the build/classes directory, but I know that I
included too much.
We use Xerces as the main parser for several
things, but its enormous monolithic size precludes
us from using it in
- Original Message -
From: Bob Jamison [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 3:46 AM
Subject: Re: [xerces2] info about some packaging changes
A SAX-only jar would be feasable, at any rate. I
have built a smaller jar that contains mostly SAX stuff
PROTECTED]]
Sent: Monday, November 26, 2001 11:39 AM
To: [EMAIL PROTECTED]
Subject: Re: [xerces2] info about some packaging changes
Ah, my confusion then! In that case (Xerces is doing a new
xmlParserAPIs.jar) my vote doesn't even count, since I was indeed
specifically talking about xml-apis.jar
[EMAIL PROTECTED] wrote:
[snip]
I.e. to me the point is that we're agreeing to ship *stable*
externally-defined standards-based files in a jar named xml-apis.jar. Any
other files a project wants to use should go in their implementation jar,
or somewhere else; and the xml-apis.jar should
you [EMAIL PROTECTED] wrote
We're planning to keep the API jar as close
to the xml-apis.jar that xml-commons produces as possible, but
obviously we won't be shipping the javax.xml.transform packages,
since we don't implement these interfaces.
Here's my:
-1 vote to Xerces'
]
Shane Curcuru/CAM/Lotus@Lotus on 11/26/2001 10:52:17 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [xerces2] info about some packaging changes
you [EMAIL PROTECTED] wrote
We're planning to keep the API jar as close
to the xml-apis.jar that xml-commons
Ah, my confusion then! In that case (Xerces is doing a new
xmlParserAPIs.jar) my vote doesn't even count, since I was indeed
specifically talking about xml-apis.jar.
On a quick read, sure, whatever Xerces wants to do like that is fine.
Longer term, perhaps after we have our next major Xalan 2.2
since reorganizing the DOM seems to be needed anyway, we thought
it might also be a good time to follow Xalan's lead and split the
API's we support and the implementation of those API's into
separate jar files. We're planning to keep the API jar as close
to the xml-apis.jar that xml-commons
