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
