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
