geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Geronimo subprojects?
Date Mon, 30 May 2005 18:32:12 GMT

On May 28, 2005, at 1:20 PM, Brian K. Wallace wrote:

> 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?

No.  Nothing.  The binary that passes the TCK is the only thing about  
which claims can be made.

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

I think that the most logical partitioning, which we've talked about  
for a loooong long time, is having the server framework separate,  
done in a way that's easily reusable by others, free of J2EE cruft,  
etc.  Then the other parts that are J2EE - in entirety, like the J2EE  
assembly - or in parts, like TX, could be separate.


> My thoughts...
> Brian
> Version: GnuPG v1.2.5 (MingW32)
> iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo
> =BFcE

Geir Magnusson Jr                                  +1-203-665-6437

View raw message