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 17:20:58 GMT
Hash: SHA1

Dain Sundstrom wrote:
| I just read through the long "Module restructure" thread, and it to  me
| is seems like many people are talking about how we break Geronimo  into
| subprojects without using the word subproject.  The goals of the
| "Module restructure" thread seem to be:
| 1) allow modules to branch to unstable without requiring the geronimo
| trunk to take unstable code
| 2) allow modules to have independent release cycles so they don't  have
| to wait for geronimo trunk
| Regardless what we call it, that is a sub project.  I think we should
| bite the bullet and talk about what sets of functionality make sense  as
| a subproject.  For example, I think there is a demonstrated desire  to
| have a TX/JCA subproject in Geronimo.
| -dain
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.

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?
~  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?
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?).

My thoughts...

Version: GnuPG v1.2.5 (MingW32)


View raw message