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.
--
Jeremy
- Re: Modular build, was: VOTE: Approach for sharing... Jeremy Boynes
-
