geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Splitting up the server into a few more chunks
Date Mon, 03 Sep 2007 12:29:50 GMT
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote:
> Another thought (now that I had some lunch....)
>
> What if we create a "builders/deployers" grouping, which contained  
> the modules and configs needed for each builder, like -
> 	deployers
> 		myfaces
> 			modules
> 				geronimo-myfaces
> 				geronimo-myfaces-builder
> 			configs
> 				myfaces
> 				myfaces-deployers
> 		tomcat
> 			. . .
> 		jetty
> 			. . .
>
> Anything that didn't fit into a deployer/builder category, could go  
> into a system grouping or the existing components group.

I forget what I said about this before... but just in case I didn't  
say it... I'm really *not* fond of grouping things under a "deployer 
(s)" name.  I think we have a core/framework, a set of reusable  
components (non-plugins, ie. tx manager, jndi provider or whatever),  
a set of plugins which provide additional functionality (could be  
deployment, could be daemon processes, whatever), a set of standard  
applications (like the web console), and a set of assemblies (which  
glue it all together).

So, based on that I think that:

     framework|core/trunk
     components/<component>/trunk
     plugins/<plugin>/trunk
     apps/<app>/trunk
     server/<server>/trunk (where server is javaee/minimal/crackpipe/ 
etc)
     uberserver/trunk (uses svn:externals to make a workspace with  
all the bits to compile for those who like to watch paint dry as the  
beast builds)

For now I'd like to see the components, plugins and apps trees  
contain separate sub-projects for each chunk of functionality,  
versioned and released independently.  I'm guessing that these  
projects might contain anywhere from 2-10 modules or so, probably  
averaging at 4, maybe 3.  Ya, I know its more moving parts to manage,  
but IMO, I think this will simplify many aspects of delivering a rock  
solid application server (and framework) to the world.  And if we do  
it right we should be able to quickly adapt and fix bugs for faster  
turn around.  And well, it will also make some of our lives a lot  
simpler since with *most* of the server being in separate smaller sub- 
projects which are released, there is a heck of a lot less code to  
build.

Well, anyways... no matter how we slice it... we need to do  
something.  And we should really get some yays and nays in the next  
week or so about the _general_ plan... and then start to stage the  
move... because it will affect developers, there will be oh-so-fun  
merges to be done, and someone is not going to be happy I'm sure...  
but we need to do it.

And, well with my code slinging cowbow hat on I'd say lets just go  
balls out and do it.  Once we have a general plan, implementing will  
take a week maybe (to get it all sorted and back to happy happy  
again), assuming there are no super-evil coupling points.

/me will shutup now

--jason


Mime
View raw message