Also.... There's a certain amount of flailing around in my (local) git commits. I don't want to spend a lot of time trying to massage these into clean atomic well-thought-out steps but I could try to do a little bit of rebasing to combine the most obviously related commits into more sensible units.
What would people like in svn?
-- to see all the incremental steps
-- to see a slightly better organized version with a few sets of commits merged together
-- to see one commit with all changes merged (I don't think this is a good idea, but it certainly is easy)
On Apr 25, 2011, at 9:38 AM, David Jencks wrote:
The tck won't run against the new code yet, only the framework server builds.
Over the weekend I resolved the git problems I was having and made a linear history version which is up to date with svn and can be pushed back into svn.
It would be easier for me to push my changes into trunk. If we make a sandbox/other copy I will have to figure out how to deal with svn branches from git, which may not be straightforward. If we make a sandbox/branch and want to turn it into trunk an svn mv rather than merge will work better.
The next steps I have in mind for the new code are to
-- make the entire server build and start
-- get the auxiliary servers (app client, various deployers) to work
Much as I'd like to get the new code into an easier-to-see location as soon as plausible, there isn't a whole lot of point to doing that unless more people are going to actively work on it.
On Apr 25, 2011, at 4:18 AM, Ivan wrote:
I am thinking that we might give an opportunity for the new trunk codes for one round TCK, if the result seems OK, we might directly work on it :-)
2011/4/25 Shawn Jiang <email@example.com>
On Mon, Apr 25, 2011 at 11:34 AM, Kevan Miller <firstname.lastname@example.org>
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.
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.