I understand your point. I guess I'm conflicted at this point as it seems like Geronimo is becoming
a Maven project :-) If the underlying tool is causing such fundamental changes to the way the
project is structured, named, etc. is the tool flexible enough?
I don't mean to start a rant or a huge debate as I know many people love Maven. I'm just commenting
that it seems like were spending more time restructuring Geronimo around Maven than we are
developing Geronimo. Seems a bit backwards.
Ok, flamesuit on :)
Guillaume Nodet wrote:
The problem with not keeping the geronimo- prefix is that all jars will end
up as
activemq-1.2.jar
activation-1.2.jar
It will be highly confusing.
The other solution is to break the directory name = artifactId rule, which
is imho
a bad idea.
On 9/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
I'm assuming everything is not geronimo- ... that might be from the
department of redundancy department.
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
>
>
>
