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)


this can be resolved by reordering, e.g.


(given that we're guaranteed backward-compatibility).

Is that correct or am I missing some subtleties here?



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.

View raw message