On May 28, 2005, at 10:20 AM, Brian K. Wallace wrote:
Agreed. And this, if properly combined with 'common deployments',
could
be a major step toward getting new users more interested.
Undoubtedly it
will require a shift in developer processes, but in the long run it
would (in theory - application of that theory being more in procedure
than possibility) make fixes and enhancements swifter.
Absolutely
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.
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.
~ 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.
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
