Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jason.dillon@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=YCfdVhRjBip9Q67e+xQu8rOT3ZMzrzkDqSnb1Z7SZR8EueVdRGcBjMxGiy8ooCqW9aEgsJi/UFc8VJJkpwR5MkyqhuLKk/2kzq2ew7s7LD6q7yCOCV16PL0jCSKCBWBPSRhYUySO+NUMYmwq7Avek6jNelN9uvzE270Yd5jl1x8=
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <44FE641B.3040808@hogstrom.org>
References: <90F6BA89-E7C1-4DBD-8806-67071C2FBB4F@planet57.com>
 <44FDCF25.9010909@hogstrom.org>
 <6FCA45AE-812C-44D8-ACB4-985D4DFEE304@planet57.com>
 <0B66DE5D-07F0-4073-8958-48E035A10286@iq80.com>
 <9C3E8101-F70B-4C77-A8FE-7D8CE7EE2D45@planet57.com>
 <2FD52D0C-ADBA-4AEB-A74C-1742C73D1344@iq80.com>
 <44FE641B.3040808@hogstrom.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <594CFDFC-3DDD-489B-9D27-B59A541E89B2@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: Restructuring trunk, then next steps
Date: Tue, 5 Sep 2006 23:21:54 -0700
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

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:

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

This is basically what I do for GShell ( http://svn.apache.org/viewvc/ 
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".

--jason


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
>>>>