Return-Path: Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 74190 invoked by uid 500); 23 Aug 2001 08:55:23 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: general@xml.apache.org Delivered-To: mailing list general@xml.apache.org Received: (qmail 74179 invoked from network); 23 Aug 2001 08:55:22 -0000 Message-ID: <8D9FDD7FE28BD41183310060082D47188324EA@nnexch-01.nfer-nelson.co.uk> From: Robert Stuart To: "'general@xml.apache.org'" Subject: RE: xml-commons XML API and API evolution Date: Thu, 23 Aug 2001 09:51:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N As a user - not a committer ... 1 - Not happy - see 3 below Set up the documentation so users can see they must download two (or more) jar files. Rhetorical question ... Can a JarPathTest class (application or applet?) be written to confirm the path to all classes required by classes inside the .jar file? Maybe ... check the jar's manifest (or entries()?) For each class in the manifest Check recursively (by reflection?) that a path exists to that class, and to classes used by that class (i.e. all super classes, interfaces, and attribute classes). To avoid duplication - keep a list of classes tested (in a Heap? ... but that decision is for the implement). Does this utility exist already? It looks like such an obviously useful utility class that a version must be out there somewhere? 2 - Bad - this breaks polymorphism. If you want to do this subclass dom with dom3, calling dom.method or dom3.method as relevant. 3 - Not happy ... the directory path from j1.jar to j2.jar must be predictable - to the developer. That is to say ... the developer must know the relative locations that the user will use for his/her jar files. How many of your local users follow the rules? -----Original Message----- From: Ben Coman [mailto:benc@sw.oz.au] Sent: 23 August 2001 00:38 To: general@xml.apache.org Subject: Re: xml-commons XML API and API evolution these a probably more mucky, but just so they are not overlooked, two things: 1. the distributions include a wrapper script which sets the appropriate classpath for each application. This wrapper script is treated as _the_ application in all examples. 2. prepend the API version to function names. ie dom2_funcname(), dom3_funcname(). 3. (Without know enough java) Is there any way that a .jar can set its own classpath? Edwin Goei wrote: > > Joseph Kesselman wrote: > > [deleted] --------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: general-unsubscribe@xml.apache.org For additional commands, e-mail: general-help@xml.apache.org