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 Thu, 31 Aug 2006 05:40:28 GMT
I had thought about calling that module 'extentions' though seemed  
odd, since out extention mechanism is called plugins.

I had also though about a 'components' tree, for optional stuff that  
can plugin, but not core to the server.

--jason


On Aug 28, 2006, at 8:02 AM, Paul McMahan wrote:

> 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