geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: Splitting up the server into a few more chunks
Date Mon, 06 Aug 2007 16:59:23 GMT
Anything more than 6 to 8 groupings could cause chaos (just like at our 
current release process which takes weeks to get everything voted and released...)

We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should contain all samples from current server and the wiki)
- components (shared/used by other projects)
- server (current catch-all)

After cleanup of server to move the samples to /samples and ApacheDS to 
/plugins, we should consider the more drastic changes, like moving the base 
Admin Console support (via Pluto 1.2) out to /plugins and start moving the 
Portlets into the actual modules/configs that they administer....

Some other "grouping" that may make sense are -
- core - renamed /server/modules directory promoted to a top-level grouping 
and only contains server modules
- configs - current configs, which can be installed as plugins
- assemblies - current assemblies, which require the configs as input


-Donald

Jason Dillon wrote:
> 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