geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <>
Subject Re: Geronimo subprojects?
Date Sat, 28 May 2005 18:02:14 GMT
Hash: SHA1

Dain Sundstrom wrote:
|> My questions at the root of this are:
|> ~  1. Assuming the whole of Geronimo passes the TCK, what can be  said of
|> a 'minimal' Geronimo? Is it able to claim anything with regard to  the
|> TCK?
| It depends on the specifications the subproject is implementing and  if
| Sun has a stand-alone tck for the specifications.  For example, if  it
| were the Geronimo 'just a webserver edition' we could certify it  for
| servlets and jsp because they have standalone tcks, but if it  were tx
| and jca we could not certify it since there are no standalone  tcks for
| those specs.
Understood. My main question was if there was some sort of 'prohibition'
on the use of 'full system' pass/fail statistics for those pieces that
do, in fact, have their own tcks. [I don't view this as a roadblock to
anything, but a definite plus if each individual piece that was able
(due to having and passing their own tcks) could state it passes.]
| On the other hand, I'm sure if enough people are interested,  sufficient
| pressure could be applied to Sun to carve a stand-alone  tck out of the
| j2ee monolith.
This I would see as a 'good thing'. Amazing how software has progressed
(*cough*) to 'smaller components combined into larger applications', but
tests (even certifications) aren't quite there yet.
|> ~  2. In stating "there is a demonstrated desire", what roadblocks or
|> opposition is there to having each of the current modules (short of  the
|> kernel, common, core and presumably deployment - and anything else
|> needed for the server to start-up and do nothing) each be
|> 'self-contained'? Obviously the 'base' server would have to know what
|> it's really capable of (unless you go off the deep end with  discovery),
|> but over and above that base it seems that a WebConnector - be it  Jetty
|> for user 1 or Tomcat for user 2 may be used with or without Naming,  with
|> or without Spring and/or Transactions, etc. Why would there be a  need to
|> limit modules just to what there is a "demonstrated desire" to have?
| Each subproject has an inherent amount of overhead.  For example,  each
| subproject needs a separate project management committee, each  one will
| need to produce releases (not an easy task) and so on.  I  would sat
| that "there is a demonstrated desire" when we have enough  people
| showing up to handle the overhead and work on the code.  I  personally
| would say one person is not enough, and seven is more then  enough.
Agreed. My view here would be to take the position "Here is the 'best
laid plan', who is willing to make it work" instead of "Here is how
people are working, what's the best plan we can come up with that
doesn't affect that". Granted, there will probably be pieces that should
probably be split out without resources to manage it, but if you aim
high you have a better chance of getting an optimal solution in place.
And nothing says that this can't be further refined down the road.
|> Making everything as small and self-contained (even if they don't  'run'
|> on their own) seems to be a smart move in allowing a bug in one module
|> to be fixed and made available without waiting on anything else (how
|> many times have we wanted a typo fixed that had to wait for a  completely
|> new feature to be implemented?).
| I think there are technical and realistic limits to this.  Some  modules
| are simply to small to be full projects.  For example the rmi
| classloadder is like 5 classes.  Also some modules naturally fit
| together and have a high degree of coupling.  For example the Tx
| manager and the j2ca implementation naturally fit together.  Now you
| can use the Tx manager standalone, but you can't really use j2ca
| without a Tx manager. Because of that linking the modules normally  move
| together.  I would say we put both in one sub project and have  them
| release two jars.
| -dain
Agreed here as well. The RMI classloader is what I consider 'too small
to make it worth it' and fell in to my "as small and self-contained" as
possible. Possible should be read with the implication of 'realistic'.
My view on the tx/j2ca type of 'module' is tempered with "overhead
costs" and agree that those types of modules may be best combined as you
stated. (although removal of that tempered view thinks they should be
separate, with the j2ca simply having a dependency on tx.)
Version: GnuPG v1.2.5 (MingW32)


View raw message