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


Reply via email to