I agree with you that managing another JAR file is a pain, and if we can
get away with not having another JAR file, I would be happy.
Jeremy, you had some good points about what a separate JAR file was
needed to allow for more flexibility, but then you and Dan had an
ongoing discussion and I wasn't sure where we ended up there. It seems
to me that if an incompatibility is detected using this classpath (where
"classpath" is defined as any type of ordering for classloading)
/home/derby/10.1/derby.jar:/home/derby/10.2/derby-client.jar
this can be resolved by reordering, e.g.
/home/derby/10.2/derby-client.jar:/home/derby/10.1/derby.jar
(given that we're guaranteed backward-compatibility).
Is that correct or am I missing some subtleties here?
Thanks,
David
Daniel John Debrunner wrote:
Another argument against putting the common code in a separate jar (e.g.
derbycommon.jar) is that both the embedded driver and client driver will
be spread across two jar files. This is the case for the IBM DB2
Universal driver and while it was the only client for the Derby network
server, we had several complaints about the two jar files. This was
because several JDBC tools expect a driver to be in a single jar, e.g.
they pop up a dialog to allow you to specify the location for a single
jar. Folks worked around this by re-jarring the IBM driver into a single
jar, I do not think this is a good approach for Derby.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
