xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alistair Hopkins" <alist...@berthengron.co.uk>
Subject RE: xml-commons XML API and API evolution
Date Thu, 23 Aug 2001 09:16:09 GMT
Also a user:

The biggest help is sensible error messages:

I don't care if it doesn't work so long as it tells me why.  If I get some
InviolableClassCastUnavailableThingException it doesn't help me, but if I
get an error that says 'you need to use dom2 in this' I'm sorted in 2
minutes.

The other thing that would go very nicely with this is a version
compatibility page on the xml.apache site: some sort of timeline, so that if
you know you have version 1.9 of fop you can use 1.17 - 1.98 of Xerces.

I like to sort my own mess out and don't want to be nannied along with
complex scripts, but a bit of help is always nice.

Alistair

-----Original Message-----
From: Robert Stuart [mailto:Robert.Stuart@NFER-NELSON.co.uk]
Sent: Thursday, August 23, 2001 9:51 AM
To: 'general@xml.apache.org'
Subject: RE: xml-commons XML API and API evolution


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



---------------------------------------------------------------------
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


Mime
View raw message