db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Sharing code
Date Thu, 08 Sep 2005 13:21:40 GMT
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.
>
>  
>

Mime
View raw message