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: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 02:57:15 GMT
Kathy Saunders wrote:
> Jeremy Boynes wrote:
>> I would argue that we are actually making life easier for people 
>> implementing simple solutions. To me, a simple environment does not 
>> need to cater for multiple versions being concurrently loaded or for 
>> multi-classloader operation; it also means being able to select just 
>> the functionality you need without having to worry about which jar 
>> file a class may have come from.
>> I think for that environment, just adding the component jars to the 
>> classpath (without any concern for ordering) is reasonable.
>> To make things even simpler, it has also been proposed that we bundle 
>> all components together into one jar (containing everything, client 
>> and server). This gives you less flexibility and a larger footprint 
>> but is a really simple solution.
>> <snip/>
> I have to say that I don't see how adding more jar files to figure out 
> whether you need to deploy and add to your classpath makes things easier 
> for the simple case.  

For the simplest case, the proposal was to package everything into one 
jar. What you don't get is minimal footprint and the ability to support 
multiple versions in the same JVM, but then those aren't really 
high-priority features for the simple case.

> And, so far, I don't see what our users would 
> reasonably be able to  pick and choose--what would they be able to leave 
> out of our database engine other than how the jar files are already 
> separated (embedded, network server, tools...)?  
> Unless I'm missing 
> something, David is currently working on internationalizing error 
> messages.  Would it really make sense to tell someone they may not need 
> that functionality? Will they be able to get error messages for network 
> server without having those classes in their classpath? I could imagine 
> scenarios in the future where there may be significant pieces of 
> functionality that we would want to separate because not everyone 
> wants/needs that functionality and it would significantly add to 
> footprint, but I can't think of anything in that category that currently 
> exists other than what we already have.  For example, we do have a 
> separate jar file for tools.
> Footprint is an interesting argument, but will we really see any 
> significant differences there yet?  Strictly looking at this from a 
> usability perspective, I still believe that having a common.jar file 
> which has no real meaning to a Derby user (since I believe you'll always 
> need in the network server case at this point), so why have them keep 
> track of yet another jar file?
> If we do have a separate jar file for these classes, I believe that it 
> should only be one at this point and classpath order should not matter.  
> Again, I'm not saying there may not be a need for more jar files in the 
> future.  I'm only looking at what I believe is proposed right now.

With the current setup, perhaps not - at this time we are only talking 
about a few common classes. However, we are talking about an 
architecture and philosophy that relies on duplication and isolation 
from any libraries, internal or external.

David has raised this issue in conjunction with messages and some common 
network functionality. I have raised it previously in conjunction with 
the implementation of our DataSources and user-visible API. That this 
keeps coming up indicates that there is something here we need to address.


View raw message