geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Restructuring trunk, then next steps
Date Wed, 06 Sep 2006 06:00:59 GMT
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
>>>
> 
> 
> 
> 

Mime
View raw message