Re: Restructuring trunk, then next steps

[Jason Dillon <ja...@planet57.com>]

I guess the rest of the proposal looks good... not sure that the  
build dependencies fit into those boxes as they are laid out though  
(and they probably don't fit into my example either).

I think we may have to stage this... probably can create framework/  
and move a few modules in there asis.  Then probably many to move  
modules/ to server/ and then start to split off modules one by one  
into a peer directory.

--jason


On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote:

>
> I'd like to propose that we keep things simple and eliminate  
> redundancy where possible.  I'd also like to keep things as brief  
> as possible to prevent current or future issues with the windows  
> pathlength issue.  I don't think the proposed changes will cause  
> immediate problems but I'd like to prevent/reduce the possibility  
> of problems.
>
> Do I understand correctly that with this proposal what is currently
> "modules/geronimo-j2ee-builder" would become
> "system/geronimo-j2ee/geronimo-j2ee-builder"
> .... and what is currently
> "modules/geronimo-j2ee" would become
> "system/geronimo-j2ee/geronimo-j2ee"?
> If so, then I think we are introducing some unnecessary redundancy  
> once again.
>
> BTW, do I understand correctly that you're proposing the removal of  
> "modules" or is this presumed to be prior to each of the new names?
>
> I wondering if it might be better to have more types and less  
> subtypes (perhaps deciding to have only a single collection of  
> types with no subtypes at all).  Perhaps something like:
>
> builders/  (not sure yet if I like this myself :-) )
>     geronimo-j2ee-builder
>     geronimo-service-builder
>     geronimo-axis-builder
>     geronimo-tomcat-builder
>     geronimo-jetty-builder
>     geronimo-security-builder
>     geronimo-service-builder
>     geronimo-connector-builder
>     geronimo-naming-builder
>     geronimo-client-builder
>     geronimo-j2ee-builder
>     geronimo-web-builder
>
> ** Note, the way we name builders and the way we name deployers is  
> inconsistent.  I think we need to decide if we want the descriptive  
> type first or last in these names and use the pattern consistently.
>
> deployers/
>     geronimo-deploy-core  (was geronimo-deployment) ?
>     geronimo-deploy-config
>     geronimo-deploy-jsr88
>     geronimo-deploy-tool
>     geronimo-deploy-hot  (was geronimo-hot-deploy ... just to be  
> consistent with other deployers but see note above) ?
>
> framework/
>     geronimo-testsupport
>     geronimo-test-ddbean (not sure what this is either)
>     geronimo-common
>     geronimo-util
>     geronimo-interceptor
>     geronimo-activation
>     geronimo-kernel
>
> server/
>     geronimo-management
>     geronimo-security
>     geronimo-core
>     geronimo-system
>     geronimo-transaction
>     geronimo-connector
>     geronimo-jmx-remoting
>     geronimo-naming
>     geronimo-client
>     geronimo-j2ee
>     geronimo-j2ee-schema
>
> features/
>     geronimo-activemq-rar (rename)
>     geronimo-activemq-gbean
>     geronimo-activemq-gbean-management
>     geronimo-axis
>     geronimo-derby
>     geronimo-directory
>     geronimo-tomcat
>     geronimo-jetty
>     geronimo-mail
>     geronimo-timer
>     geronimo-webservices
>
> tools/
>     geronimo-upgrade
>     geronimo-converter
>
>
> Joe
>
>
> 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