Ops, modifying title will bread the gmail thread. Added the same comments to the original thread.
Please ignore this mail. On Mon, Apr 25, 2011 at 5:34 PM, Shawn Jiang <[email protected]> wrote: > > > On Mon, Apr 25, 2011 at 11:34 AM, Kevan Miller <[email protected]>wrote: > >> As you know, David Jencks has been working on restructuring Geronimo to >> move away from the Geronimo's ConfigurationManager and DependencyManager and >> use standards based OSGi mechanisms. >> >> I took a look at his current code -- >> http://people.apache.org/~djencks/22-4-2011.full.bundle (I used git clone >> 'git clone ~/downloads/22-4-2011.full.bundle geronimo' and 'git checkout >> arch3' to create a working copy). After running 'mvn -N' I was able to build >> successfully (well build up to framework assembly at which point there's an >> IANAL-style check for license/notice files). The resulting framework server >> starts and, IMO, things are looking pretty good. >> >> I think it's time to start getting more eyes on this work. Assuming we >> like the direction, I'd like to see this code in trunk. Allowing multiple >> people to start working on further integration. >> >> An alternative would be to create a sandbox/branch for this new work. >> However, I'm more inclined to go with trunk. Here's how things could work: >> > > With the later options, we need to re-setup m2 dev/AHP/build environment > immediately and have to maintain two set of code for tck for an unknown > period. I'd prefer the sandbox/branch instead of branching current trunk > before major potential issues in the new kernel is resolved. > > Here are the possible working logic if choosing the sandbox option: > > 1, Run full tck/SVT against the sandbox branch to find the gaps. > 2, Keep resolving the Major issues until we are comfortable to put it into > trunk. > 3, Branch current trunk to new M2 when the sandbox branch is ready. > 4, Merge the sandbox branch to trunk. > > Thoughts ? > > >> >> Create a new branch off of current trunk and use this branch for continued >> TCK testing. This assumes that fixes for TCK problems do not have much >> overlap with changes for the new server structure -- I think this will >> largely be true. This does imply that TCK fixes will need to be merged into >> trunk. This seems better than other alternatives. Though I'd certainly >> listen to other options/opinions. >> >> One option for this new branch is to call it 3.0-M2 (and abandon the >> current M2 branch). I'd really like to see us get a web profile compliant >> Milestone release. Would be useful for our users, anyway... >> >> I'm hopeful that our switch over to the new trunk codebase can go pretty >> quickly. I think we certainly want to minimize time with two active >> development branches/trunks. >> > > I agree we want to minimize time with two active developement branches. > > >> >> Thoughts? >> >> --kevan >> >> > > > -- > Shawn > -- Shawn
