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 18:23:00 GMT
I'd rather not have another level to simply separate code jars from  
config jars...  I think they should all live together, and if needed  
we suffix the config bits with "-config", so you'd have:

    activemq-broker
    activemq-broker-config
    activemq-ra
    activemq-ra-config

IMO, no need for another level of nested directories.

But regaurdless, my drive here is to help make it easier for folks to  
develop G and develop G plugins w/o having to build the entire  
server, which as well all know can be problematic from time to time.

--jason


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.
>
>
> Then again, maybe we need to step back from the current source code  
> structure and think more along the lines of Lego blocks or OSGi  
> bundles in a server, agree to what that "framework" would look like  
> and then slice and dice our current .m2 structure into those new  
> buckets.....
>
>
> -Donald
>
> Donald Woods wrote:
>> 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