geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Splitting up the server into a few more chunks
Date Mon, 06 Aug 2007 18:12:41 GMT
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 -
			. . .
			. . .

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

View raw message