| Ya, this is one of the main reasons.
We don't have to have geronimo-* in infront of everything, for example our activemq integration might be in:
components/ activemq-component/
This, plus the groupId makes it clear enough... but we should not call the module activemq.
* * *
Its sad and a little frustrating, that an email about structure ends up as some complains about naming conventions.
:-(
--jason
On Sep 5, 2006, at 12:36 PM, 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
>
>
>
--
Cheers,
Guillaume Nodet |
