Restructuring trunk (LONG)

2007-03-30 Thread Jason Dillon
Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I had been waiting for svk2 to be usable enough to manage restructuring in a branch while pulling in new changes to src files, and the latest updates to the svk2

Re: Restructuring trunk (LONG)

2007-03-30 Thread David Jencks
This is great! thanks for looking into this! So far I have only a couple minor quibbles. -- connector + transaction should be a component -- I don't understand why you want the "server" in the base groupId. why not o.a.g.activemq, o.a.g.connector, o.a.g.openejb, etc? o.a.g.server.client se

Re: Restructuring trunk (LONG)

2007-03-30 Thread Jason Dillon
On Mar 30, 2007, at 2:50 PM, David Jencks wrote: This is great! thanks for looking into this! Thanks for taking the time to read what I wrote :-) So far I have only a couple minor quibbles. -- connector + transaction should be a component That should work... though some bits like geronimo

Re: Restructuring trunk (LONG)

2007-03-30 Thread Jason Dillon
On Mar 30, 2007, at 2:50 PM, David Jencks wrote: This is great! thanks for looking into this! So far I have only a couple minor quibbles. -- connector + transaction should be a component It might actually turn out that more modules that are currently listed in framework/* could be moved to

Re: Restructuring trunk (LONG)

2007-04-03 Thread Donald Woods
I like your proposal, but this feels like a major change to make in the last month of a release, when we are just now seeing and fixing Console bugs and the Samples still need work for 2.0. Waiting until after M5 (or after CTS setup is finished) to start changing any of the groupIds could caus

Re: Restructuring trunk (LONG)

2007-04-03 Thread Jason Dillon
On Apr 3, 2007, at 7:11 AM, Donald Woods wrote: I like your proposal, but this feels like a major change to make in the last month of a release, when we are just now seeing and fixing Console bugs and the Samples still need work for 2.0. Waiting until after M5 (or after CTS setup is finished

Re: Restructuring trunk (LONG)

2007-04-09 Thread Prasad Kashyap
Went through your (quite interesting) doctoral dissertation and added some comments inline :-) Cheers Prasad. On 3/30/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Awhile back I sent some email [1] about restructuring server/trunk into smaller groups of modules organized by function/feature. I h

Re: Restructuring trunk (LONG)

2007-04-09 Thread Jason Dillon
On Apr 9, 2007, at 11:08 AM, Prasad Kashyap wrote: Went through your (quite interesting) doctoral dissertation and added some comments inline :-) :-) This isn't going to be possible for all of our dependencies, though I think that if we can move to this model it would help improve the mainta

Re: Restructuring trunk (LONG)

2007-04-10 Thread Donald Woods
Inline below... -Donald Jason Dillon wrote: On Apr 9, 2007, at 11:08 AM, Prasad Kashyap wrote: Went through your (quite interesting) doctoral dissertation and added some comments inline :-) :-) This isn't going to be possible for all of our dependencies, though I think that if we can move

Re: Restructuring trunk (LONG)

2007-04-10 Thread Jason Dillon
On Apr 10, 2007, at 7:08 AM, Donald Woods wrote: What repositories? Most of these artifacts live in central... and according to Jason Van Zyl, artifacts in central are never removed. And he isn't so found of adding extra magical repository bits to subvert the system. I was looking at makin