geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: Restructuring trunk, then next steps
Date Thu, 31 Aug 2006 15:04:41 GMT
+1 on this proposal

On 8/31/06, Joe Bohn <joe.bohn@earthlink.net> 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
> >
> >
>

Mime
View raw message