----- Original Message ----- From: "Jason van Zyl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 18, 2002 7:20 PM Subject: Re: SAX classes in JAR wreaking havoc [snip]
> > We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with > > MinML (the MinML distribution contains this subset). Note that moving to a > > later version of the SAX1 classes will cause deprecation warnings as the SAX > > 1 stuff has now been deprecated in favour of SAX2. > > > > At some point we might want to consider moving from SAX1 to SAX2 (and from > > MinML to MinML2). It buys us precisely nothing in terms of functionality but > > does not have any significant cost in terms of performance. > > So what does this mean now? The presence of the classes are causing > problems. I thrown together a JAR without those classes to get the > Turbine builds working again but this is a stopgap solution. Can we > package the ancillary classes in a second JAR and tell people to use > this if they need to? This is how it was originally wasn't it? There are several options: 1/ Produce "stand alone" and "servlet" jars. The "stand alone" jar contains all the client code, the small HTTP server and the server code plus MinML and the SAX1 classes. The "servlet" jar contains the Servlet wrapper but not the SAX classes or the HTTP server. 2/ Move the SAX classes into a separate jar (this would not be needed at all if the code was run under JDK 1.4 or later). 3/ Move the SAX classes and MinML into a separate jar. 4/ Remove MinML and the SAX classes from the distribution altogether. I quite like option 1 - I think it reflects the reality of the two distinct classes of use of this stuff. John Wilson The Wilson Partnership http://www.wilson.co.uk
