geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Geronimo subprojects?
Date Sat, 28 May 2005 17:57:17 GMT
So far I am completely unconvinced by any arguments in this thread.

As a thought experiment, lets suppose we had already released a 
certified geronimo, say last month, and we had solved most of our build 
problems, say with maven2.  So, we have a certified branch and trunk, 
and all the geronimo developers are happily working on new features on 

In this scenario exactly what needs changing and why?

david jencks

On May 28, 2005, at 10:38 AM, Dain Sundstrom wrote:

> 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

View raw message