geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Restructuring trunk, then next steps
Date Mon, 11 Sep 2006 17:06:38 GMT
Please help me try to understand this -

Will our jars will be taken/seen/used outside the Geronimo context ?
If they are, then I agree that geronimo-activation-1.2.jar is more
meaningful than a simple activation-1.2.jar. The latter also gives
scope for name conflicts.

But if our jars are always seen in the Geronimo context, we already
have the o.a.g groupId to fully qualify it as a Geronimo jar. The jars
will always be in a maven repo under o.a.g groupID. Why then should we
need to prepend the "geronimo-" to our artifacts.

NOTE: I completely agree that our directory structure should match the
artifactId. I am not suggesting that we deviate from the maven
convention. I am just wondering why we can't can't drop the
"geronimo-" qualifier in both the directory name and artifactID. Maybe
I'm missing something and hope you'll help me see it.

Jason, here's a big +1 to your proposal to restructuring the modules.
I am not against that. But this would be a good time to do some
renaming if we can while we can. Hence this thread apparently seems to
have veered off the topic. But actually it hasn't. I hope.

Cheers
Prasad

On 9/5/06, Guillaume Nodet <gnodet@gmail.com> 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 <matt@hogstrom.org> 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

Mime
View raw message