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 <[EMAIL PROTECTED]> 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
