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: local policy)
Message-ID: <44FE722C.4070402@hogstrom.org>
Date: Wed, 06 Sep 2006 03:01:00 -0400
From: Matt Hogstrom <matt@hogstrom.org>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Restructuring trunk, then next steps
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> <2
 <594CFDFC-3DDD-489B-9D27-B59A541E89B2@planet57.com>
In-Reply-To: <594CFDFC-3DDD-489B-9D27-B59A541E89B2@planet57.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ok, point taken on my pedantic and redundant rant.  Of course I got sidetracked.

I like the structuring a lot.  I think there are a number of different ways to organize it and if 
you ask my wife I'm not one to be giving organizational input ;-)  One thing that makes sense to me 
is organization by function.  So, in you example, I'd put the builders together, deployment, etc. 
rather than putting them in their respective modules.  Just my odd way of thinking.

System seems to made up of the core elements of Geronimo.  Are we missing a /distributions or 
/server element?  It would be awesome to only have to change the version of the distributions in one 
place.

Another thought that we are dealing with right now in the 1.1.1 release is co-releasing components. 
  For instance, the 1.1.1 server is dependent on several other components (Open EJB, the specs, 
etc.) and they need to be released at the same time.  We could either release the components 
independently and the server would simply certify a set or choose to co release the components at 
the same time.

I think the former is desireable but a PITA to coordinate voting of multiple components over several 
days (and how would people approve them?  Unit test cases?)  or trying to coordinate multiple rcn 
releases which is also very difficult.  David Blevins has been waiting patiently for OEJB to be 
released so he can move it to the incubator.

Anyway, I think we definitely need a /server which would be the minimal Geronimo server (w/o a web 
container that plugins can be installed into) and a /dist for the J2EE certified server versions.

Jason Dillon wrote:
> 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
>>>>>
> 
> 
> 
>