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 Mon, 28 Aug 2006 15:02:54 GMT
Jason, the distinction between "framework" and "system" might be
unclear to a novice.  Something like "bootstrap" and "system" might be
clearer.  Also, I think of "plugin" as a packaging/distribution
mechanism instead of a statement of functionality so I would call that
directory something like "ext" and put modules in there that are
optional extensions to the server (probably implemented as plugins,
but not necessarily).

Best wishes,
Paul

On 8/28/06, Jason Dillon <jason@planet57.com> 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