Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DD9342E10 for ; Mon, 25 Apr 2011 16:38:36 +0000 (UTC) Received: (qmail 53974 invoked by uid 500); 25 Apr 2011 16:38:36 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 53895 invoked by uid 500); 25 Apr 2011 16:38:36 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 53888 invoked by uid 99); 25 Apr 2011 16:38:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Apr 2011 16:38:36 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.57] (HELO smtp102.prem.mail.sp1.yahoo.com) (98.136.44.57) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 25 Apr 2011 16:38:28 +0000 Received: (qmail 22958 invoked from network); 25 Apr 2011 16:38:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=0aXj/k9Gc9YpIoRJeOhG7Nj2FtEWnZjtfKz2iiuQU26PLiqW9+Z4YmenQ8dPxpeSTzA3KeFW2XAUtjROCiG5dL9vbbTEIueusfWz8kvzhtnGpLIq0EmkD+pNIUw5Di4r7vWfsEDYn1BGVybPB9yZAOc/HOaFZaqZHEou7apetg0= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303749486; bh=ZLovw+CvuE9zVErvaMpD2YHUvzuPQ0kOr62XWBlaRes=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=fryHXpZ4BHMF6qJYLEbcUngY30HmtyWiXkRzZiKCz5M8+sK21LMpoPSuV+p3Q92PX/hSjNwlTYtn2XCc/O0Ek+6rs5dGICzVqNmjcoqXL/D8nU6ivwybz8YfY4n2E0zmsL59v714e0ybjEY485ZqyjKSC47k/Gah1+yu9SXkNO4= Received: from [10.0.1.147] (david_jencks@76.76.148.215 with plain) by smtp102.prem.mail.sp1.yahoo.com with SMTP; 25 Apr 2011 09:38:05 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: WdWYUSgVM1kuyDN9EnOnMD5LBMn8xlw5og4ye10ez7mhd15 iXReWL5q.kkDyM.d7NPUmyv7hwNpVtHS1GK1Y.iA43VG07tmKvu.Qx_bIpnc NafT8gUxBSsIU57LCqc5HEifNZJOjQMl9nkC2IPRXTMgY162g2vrSDGE_Sgc b9k.LZyatk9VEHb5M6Lbx2cfiKFdTHvVKTBBIAdSonL1VNefpWPMDTYhrRNC phCizXxqzYFYwXiCUdkvE1.6thZqgs_.61DHoFURbruj08HOU8Y.wluglZZ6 PxYY6c1F8pT0nVpXZTNnYqkvPrVABq70EetgbQZtd9d0CgRqVmCL5fBYRhpn 70otJsMd1aHvtZM9lOwpeCDcAtrY_7OrSpoyJ4JyHOA-- X-Yahoo-Newman-Property: ymail-3 From: David Jencks Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--975229647 Subject: Re: Time for trunk res Date: Mon, 25 Apr 2011 09:38:04 -0700 In-Reply-To: To: dev@geronimo.apache.org References: Message-Id: <1AE1C4DD-BCB4-4AB6-A7B1-B33A1E3DF5AC@yahoo.com> X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-1--975229647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. thanks david jencks 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 :-)=20 >=20 > 2011/4/25 Shawn Jiang >=20 >=20 > On Mon, Apr 25, 2011 at 11:34 AM, Kevan Miller = 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. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > 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. =20 >=20 > Here are the possible working logic if choosing the sandbox option: >=20 > 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. >=20 > Thoughts ? >=20 > =20 >=20 > 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. >=20 > 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... >=20 > 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. > =20 >=20 > Thoughts? >=20 > --kevan >=20 >=20 >=20 >=20 > --=20 > Shawn >=20 >=20 >=20 > --=20 > Ivan --Apple-Mail-1--975229647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.

thanks
david = jencks


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 <genspring@gmail.com>
=


On Mon, Apr 25, 2011 at 11:34 = AM, Kevan Miller <kevan.miller@gmail.com> 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<= /a> (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:

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.

Thoughts?

--kevan




--
Shawn



--
Ivan

= --Apple-Mail-1--975229647--