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 07:01:53 GMT
Hehehehehe...no, that'll be fine :)  I get it.

Jason Dillon wrote:
> And here you go again... or do you need this in triplicate?
> 
> :-P
> 
>  * * *
> 
> 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
>>>>>
> 
> 
> 
> 

Mime
View raw message