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 Wed, 14 Sep 2005 01:25:11 GMT
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/>

> 
> 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

Mime
View raw message