geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Restructuring trunk, then next steps
Date Tue, 05 Sep 2006 21:27:42 GMT
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