db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Sharing code
Date Sun, 04 Sep 2005 15:49:56 GMT
David W. Van Couvering wrote:
> 
> The common classes will be placed into both derby.jar and 
> derbyclient.jar.  When you have a classpath with a network client at one 
> revision and the embedded driver at another revision, the jar with the 
> highest revision should always go first, e.g 
> "/home/derby/10.2/derbyclient.jar:/home/derby/10.1/derby.jar".  This 
> ensures that the newer code that depends on new interfaces (e.g. a new 
> method for a class) will be able to function properly.

Others have pointed out the problems here with classpath ordering.

The root of this is that the same classes are being included in multiple 
jars leading to potential duplication. This can be avoided by placing 
them in a separate jar so that each is only present once e.g.

derby-10.2.jar:derbyclient-10.2.jar:derbycommon-10.2.jar

The downside of this is that multiple jars need to be included to form a 
complete solution. Concern has been expressed in the past about 
exceeding the length of the CLASSPATH environment variable. However, 
most frameworks today, including J2EE, do not use that mechanism to 
include libraries relying instead on features like the manifest 
classpath, extensions, WEB-INF/lib, uber-jar or others provided by a 
container environment.

IMO the benefits of a more modular structure and a clear lack of 
duplication exceed the benefits of a bundled distribution and I would 
prefer to see the common code distributed separately.

--
Jeremy

Mime
View raw message