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, 06 Aug 2007 15:17:18 GMT
Um, I just took a blind stab in the dark...

But, what I was thinking was that we have  the core modules which are  
the bare minimum to boot up a functional Geronimo server w/o any  
JavaEE muck, then slice up the other components into plugins, though  
they don't really need to be G plugins, they just need to hold groups  
of modules to provide a components functionality and configuration.

I also split up the support bits, as those should be common across  
the core framework bits and components/plugins...

I'm certainly open to ideas and discussion on this.  I think we  
really need to move in this direction.

--jason


On Aug 6, 2007, at 8:12 AM, David Jencks wrote:

> I certainly agree with your goal but am less sure about your  
> proposed naming and organization.  Also from looking at your list  
> it took me a couple minutes to figure out what is removed from  
> "server"
>
> I've been thinking that we could proceed by turning bits of the  
> server into plugins.  For instance I was planning to turn the  
> directory bits I commented out recently into a plugin this week.  I  
> think we could fairly easiiy turn jetty, tomcat, and openejb into  
> plugins.  I wonder if, after turning the "easy stuff" into plugins  
> what we will think about reorganizing the remaining stuff.
>
> So then the question might be how to organize the plugins?
>
> thanks
> david jencks
>
> On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote:
>
>> Hiya, I've mentioned this before... and now that we have a 2.0  
>> branch and trunk has moved on to 2.1 work, I think its time we  
>> really make a decision on this and implement it.
>>
>> Before, I had been thinking of keeping all of the modules in the  
>> server/trunk tree just in better locations organized by  
>> functionality and feature not by artifact type.  But, now I'm  
>> thinking we should really do one step more than that, and split up  
>> the server/trunk project into several smaller and more manageable  
>> chunks of modules.  I still think that the basic grouping that we  
>> kinda talked about before should work fine, but instead of having  
>> them share a project namespace we give them their own.
>>
>> So, for example...
>>
>> server-support/trunk
>>     testsupport
>>     buildsupport
>>
>> server-framework/trunk
>>     geronimo-activation
>>     geronimo-client
>>     geronimo-client-builder
>>     geronimo-clustering
>>     geronimo-common
>>     geronimo-connector
>>     geronimo-connector-builder
>>     geronimo-core
>>     geronimo-deploy-config
>>     geronimo-deploy-jsr88
>>     geronimo-deploy-jsr88-bootstrapper
>>     geronimo-deploy-tool
>>     geronimo-deployment
>>     geronimo-gbean-deployer
>>     geronimo-interceptor
>>     geronimo-j2ee
>>     geronimo-j2ee-builder
>>     geronimo-j2ee-schema
>>     geronimo-jmx-remoting
>>     geronimo-kernel
>>     geronimo-management
>>     geronimo-naming
>>     geronimo-naming-builder
>>     geronimo-security
>>     geronimo-security-builder
>>     geronimo-service-builder
>>     geronimo-system
>>     geronimo-test-ddbean
>>     geronimo-timer
>>     geronimo-transaction
>>     geronimo-transaction-jta11
>>     geronimo-transformer
>>     geronimo-util
>>     geronimo-web-2.5-builder
>>
>> And then we can group some of the related components up into  
>> shared projects, or just go out and give each component its own  
>> project, and/or think about maybe using the same style that the  
>> maven/plugins/trunk tree uses, a shared project, but each  
>> component is related individually... still not sure I like that,  
>> kinda messy.
>>
>> I don't want to end up with a ton of projects either, and I  
>> certainly don't want to get up using SNAPSHOT versions of these  
>> puppies if we can help it.  So, maybe to start out we could do these:
>>
>>     server-support
>>     server-framework
>>     server-components
>>     server-assembly
>>
>> BTW, I'm using "dash" here so that the names don't collide with  
>> what is there now, but really we could user server/support/trunk,  
>> server/framework/trunk, etc (which is better IMO for the longer run).
>>
>> And in the process of making this split up, we can re-arrange  
>> modules by feature and function instead of by type... and actually  
>> we have to do that to make the components bits work.
>>
>>  * * *
>>
>> I really believe this will help improve the support and  
>> maintainability of the server's code-base and it will help the  
>> project scale better as new components are added too.  For  
>> developers that are only interested in working on a specific  
>> component, it reduces the amount of other sources they need to  
>> check out and reduces the time to build too, so that they can  
>> build a clean server assembly faster and developer their features  
>> sooner and hopefully have less hair-pulling and more relaxed beer  
>> drinking as they pat themselves on the back for doing such a  
>> speedy job.
>>
>> I really, really... really, really, really ( :-P ) think that we  
>> *must* move along these lines for the longer term health of the  
>> project...
>>
>> Comments?  Suggestions?
>>
>> --jason
>>
>>
>


Mime
View raw message