geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Restructuring trunk, then next steps
Date Thu, 31 Aug 2006 14:26:49 GMT

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

Mime
View raw message