db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathy Saunders <kat...@mtrad.com>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 14 Sep 2005 16:59:19 GMT
Jeremy Boynes wrote:

> Kathy Saunders wrote:
>
>>
>
> <snip/>
>
>>
>> I'm a bit concerned because I see a lot of discussion about what is 
>> good from a derby development perspective, but not so much how these 
>> changes may affect users of Derby.  Although some Derby users have 
>> complex applications (like application servers), many are 
>> implementing much more simple solutions.
>
>
> 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.  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.

>>
>> In addition, I work on Derby now in the testing area, so I'd also 
>> like to understand the implications for what additional testing might 
>> need to be done.  If we create more jar files, is there more testing 
>> requirements for different combinations?
>>
>
> I don't think there are any more combinations - in fact probably less 
> as you would not need to test all possible classpath orderings. We are 
> dealing with the same amount of code, just modularizing its structure.
>
> By modularizing the build we also allow for in-depth testing on each 
> individual component in isolation. With a clear definition of the API 
> contract for each component and testing (unit, functional, 
> compatibility) of that contract we can perform more thorough testing 
> on each one before integrating into a whole. Integration and system 
> testing can focus on the interfaces between components rather than on 
> the entire black box.
>
> Add in too that modularization makes it easier for users and 
> developers to come up to speed with the design and implementation of 
> that component. More eyes on the code with comprehensible component 
> leads to better review and higher quality.
>
> Finally, you can see this pattern at work with many open source 
> projects: a common core and then a very modular structure that allows 
> people to participate at the component level. Examples of projects 
> with this type of structure are:
> * Apache HTTPD + mod_*
> * Apache Maven + plugins
> * Eclipse + plugins
> * Apache Jakarta/Tomcat + Commons
> and many more.
>
> -- 
> Jeremy
>
>
>
>
Thanks for your perspective on the testing issue.

Kathy


Mime
View raw message