geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Restructuring trunk, then next steps
Date Tue, 05 Sep 2006 21:42:15 GMT
Please don't get mad at me, but I'd like to move a bit slower on more  
classification inside of the server module.  I'd like to pull  
transaction and connector out to independently versioned modules and  
then see if the tree still feels crowded.

-dain

On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote:

> I am sure that some of these names will change...
>
> But the directory name should be the same as the artifactId... so  
> that its easy to see where the source for artifacts come from, and  
> because some maven plugins that work on sets of modules make that  
> assumption (like site plugin for example) when running.
>
> This is a best practice with Maven... and I don't recommend moving  
> away from that.
>
> Before we already had things like console-jetty making a jar named  
> webconsole-jetty-* and others too which only make it more difficult  
> to tell where these things come from.
>
> --jason
>
>
> On Sep 5, 2006, at 12:25 PM, Matt Hogstrom wrote:
>
>> I'm assuming everything is not geronimo- ... that might be from  
>> the department of redundancy department.
>>
>> Jason Dillon wrote:
>>> So, I've mentioned a few times before that we should start  
>>> thinking about how to split up modules in trunk into a few  
>>> smaller chunks.  I took a few minutes and took a crude stab at  
>>> what that might look like.  This is just an example of how it  
>>> might work... I did not do any extensive research into  
>>> dependencies...
>>> Basically, I split things up into 5 main trees:
>>>  * framework - common stuff, not really the server, but supports  
>>> the server, modules here should have minimal deps
>>>  * system - the major components which make up the server's  
>>> system (should be the bits to start up a server shell)
>>>  * tools - bits that support the system
>>>  * plugins - components which plugin to the system
>>>  * testsuite - placeholder for modules which will be aded soon  
>>> that use the itest plugin to perform integration tests
>>> I'm not sure if this is the best split, but it kinda comes closer  
>>> to what I hope we can get to.  Below is how the modules that  
>>> exists fit into these sections.
>>> ----
>>> framework/
>>>     geronimo-testsupport (may need to be in other tree? so can  
>>> include in all modules by default)
>>>     geronimo-common
>>>     geronimo-util
>>>     geronimo-interceptor
>>>     geronimo-activation
>>>     geronimo-kernel
>>> system/
>>>     geronimo-management
>>>     geronimo-security
>>>     geronimo-security-builder
>>>     geronimo-service-builder
>>>     geronimo-core
>>>     geronimo-system
>>>     geronimo-transaction
>>>     geronimo-connector
>>>     geronimo-connector-builder
>>>     geronimo-jmx-remoting
>>>     geronimo-naming
>>>     geronimo-naming-builder
>>>     geronimo-test-ddbean (wtf is this for?)
>>>     geronimo-deployment/
>>>         geronimo-deployment (rename to -core) ?
>>>         geronimo-deploy-config
>>>         geronimo-deploy-jsr88
>>>         geronimo-deploy-tool
>>>         geronimo-hot-deploy
>>>     geronimo-client
>>>     geronimo-client-builder
>>>     geronimo-j2ee/
>>>         geronimo-j2ee
>>>         geronimo-j2ee-builder
>>>         geronimo-j2ee-schema
>>>     geronimo-web-builder
>>> plugins/
>>>     geronimo-activemq/
>>>         ge-activemq-rar (rename)
>>>         geronimo-activemq-gbean
>>>         geronimo-activemq-gbean-management
>>>     geronimo-axis
>>>     geronimo-axis-builder
>>>     geronimo-derby
>>>     geronimo-directory
>>>     geronimo-tomcat
>>>     geronimo-tomcat-builder
>>>     geronimo-jetty
>>>     geronimo-jetty-builder
>>>     geronimo-mail
>>>     geronimo-timer
>>>     geronimo-webservices
>>> tools/
>>>     geronimo-upgrade
>>>     geronimo-converter
>>> testsuite/
>>>     TODO, home for itest usage
>>> ----
>>> Anyways, I wanted to post what I am thinking.  I think that we  
>>> are really close to the point where we will want to implement  
>>> this sort of split up.
>>> Comments?
>>> --jason


Mime
View raw message