geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Restructuring trunk, then next steps
Date Wed, 06 Sep 2006 06:21:54 GMT
Matt, I have already explained why... at least twice :-P

If we want to remove the geronimo- prefix, then lets rename the  
artifacts... which I think should be done anyways when the modules  
are split up into smaller groups.

For example, if we have a components/ tree, which groups optional  
components (stuff that is non-core), as in:

     activemq-component (makes activemq-component-*.jar)
     axis-component (makes axis-component-*.jar)

This is basically what I do for GShell ( 
geronimo/sandbox/gshell/trunk/ ) though I do have the prefix on  
children... but in this case gshell- is smaller than geronimo-

When I made that initial stab at a rough layout, I copied all of the  
names as they were... so they al have geronimo- on them, but I hope  
that as we move things about to organize them better that we can  
change the artifact names removing the geronimo-* prefix, but  
including the group in the artifactId someway.

I agree its redundant to to say these artifacts are geronimo-*, but  
we need to add some other classifier...

I firmly believe that it is best to keep the directory and  
artifactId's the same.

Maybe I should write up another crude tree example, with better  
names... since many folks (like.. um... you :-P) seem to be hung up  
the "naming" and missing the point about the "structure".


On Sep 5, 2006, at 11:00 PM, Matt Hogstrom wrote:

> Is this a must have or a nice to have?  Everything in the tree is  
> already geronimo and nicely fits in a geronimo dir in the maven  
> repo.  Can someone from Maven enlighten me as to why the redundancy  
> is necessary and how redundancy is a good thing to be redundant.   
> Not to repeat myself, but I guess I'm not getting why redundancy is  
> good.
> You might need to send me two e-mails of the same information so I  
> remember that I was asking about redundancy :)
> What was I talking about?  Oh yeah, redundancy.
> Seems odd that the server structure has to match the build system.   
> Isn't that a bit of bleed through?  Oh gosh, there I go again being  
> redundant.  Sorry, I'm repeating myself, oh, there I go again.   
> Sorry...oops, one last time.   ;-P
> Dain Sundstrom wrote:
>> BTW I do think we should rename the dirs to match the maven  
>> standard geronimo-foo standard.
>> -dain
>> On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote:
>>> Fine with me.
>>> The tree is still in need of reorganization even after those  
>>> modules are gone.
>>> --jason
>>> On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote:
>>>> Please don't get mad at me, but I'd like to move a bit slower on  
>>>> more classification inside of the server module.  I'd like to  
>>>> pull transaction and connector out to independently versioned  
>>>> modules and then see if the tree still feels crowded.
>>>> -dain
>>>> On Sep 5, 2006, at 2:27 PM, Jason Dillon wrote:
>>>>> I am sure that some of these names will change...
>>>>> But the directory name should be the same as the artifactId...  
>>>>> so that its easy to see where the source for artifacts come  
>>>>> from, and because some maven plugins that work on sets of  
>>>>> modules make that assumption (like site plugin for example)  
>>>>> when running.
>>>>> This is a best practice with Maven... and I don't recommend  
>>>>> moving away from that.
>>>>> Before we already had things like console-jetty making a jar  
>>>>> named webconsole-jetty-* and others too which only make it more  
>>>>> difficult to tell where these things come from.
>>>>> --jason
>>>>> On Sep 5, 2006, at 12:25 PM, Matt Hogstrom 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

View raw message