I think that in decreasing order of importance when designing and building Geronimo, that we should aim for:
1) Functionality -- it should do everything that we expect a J2EE environment to do
2) Easy to use and administer
3) Easy to develop and maintain
4) Efficient (memory, computational speed, whatever)
I don't think anyone would argue with (1), but if we want Geronimo to be the best (and I'm pretty sure that we are all aiming that way) then it probably has to be easy to use and administer over and above development ease. But it may be that (2) and (3) could be reordered.
I also think that in order to address (3) there are benefits in linking up with as many other projects as possible, rather than develop a Not Invented Here syndrome. I am not an Apache member, so I don't know The Apache Way (maybe someone can fill it in here), but what it means to me is that Apache builds projects that are useful, and that may then be integrated into other Apache projects. That certainly seems to be the case with the jakarta-commons packages, and indeed there are several packages which have been built on top of others (James on top of Avalon, Jetspeed on top of Turbine/Velocity, not to mention the uses of the commons- packages).
I know that the current focus is on (1) (and probably (2/3) as well) for the project, and so a getting-there-fast approach is probably a good idea. But let's not write off trying to use other parts (and keep them!) from the Apache projects when they're useful; after all, object orientation is mainly about reuse.
I personally think that (4) should be the last point on the list, by some way. J2EE servers are going to be notoriously powerful beasts, and whilst it would be advantageous to run on constrainted hardware, I really don't think that's where the target customer base is going to be. And as the J2EE spec keeps growing, just to cater for (1) we're going to have a lot of code. Optimisations that therefore target (4) at the expense of (3) IMHO are going the wrong way; for example, ditching the commons packages because Geronimo code (as yet) only uses one ReferenceMap.
I also feel that at this stage of the project, trying to squeeze performance out of component X isn't the best use of (3). If we have two designs, one easier to maintain/extend, and one that is fast, I'd prefer the former. Why? Because I don't know that the latter is necessarily that much faster, and for that matter, don't know that it is in the bottleneck of the code. And until we get a working version that we can start running and profiling to find out where the bottlenecks are, any optimisation is premature optimisation.
Just my $0.02
Alex.
