From cloudstack-dev-return-16245-apmail-incubator-cloudstack-dev-archive=incubator.apache.org@incubator.apache.org Tue Jan 8 22:32:17 2013 Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 212D0E7FB for ; Tue, 8 Jan 2013 22:32:17 +0000 (UTC) Received: (qmail 2239 invoked by uid 500); 8 Jan 2013 22:32:16 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 2195 invoked by uid 500); 8 Jan 2013 22:32:15 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 2159 invoked by uid 99); 8 Jan 2013 22:32:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jan 2013 22:32:15 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Alex.Huang@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jan 2013 22:32:11 +0000 X-IronPort-AV: E=Sophos;i="4.84,433,1355097600"; d="scan'208";a="3097554" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 08 Jan 2013 22:31:50 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Tue, 8 Jan 2013 14:31:49 -0800 From: Alex Huang To: "cloudstack-dev@incubator.apache.org" Date: Tue, 8 Jan 2013 14:31:50 -0800 Subject: RE: [MERGE] Merge Javelin branch into master Thread-Topic: [MERGE] Merge Javelin branch into master Thread-Index: Ac3t7c5JvzHBa41nT8GenT4d95c6pwAAgW8w Message-ID: References: <0BF8BD33-C803-4E49-B3F4-B5128D677ACE@basho.com> <65412DD7-74E6-470A-B2CE-F84244DE106F@basho.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org To do it is not that difficult. One person can probably do it in a day. B= ut I think Chip is saying that it was decided to keep the current directory= structure because that question was asked b4. --Alex > -----Original Message----- > From: Mohammad Nour El-Din [mailto:nour.mohammad@gmail.com] > Sent: Tuesday, January 08, 2013 2:16 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [MERGE] Merge Javelin branch into master >=20 > Hi... >=20 > For the points about following or not following the std Maven director= y > structure, I would suggest to do it after merging Javelin into master bra= nch >=20 > Is there a separate branch for updating similar maven configurations ? or > making our poms comply to the std Maven conventions ? >=20 > If not would it be worthy to create that branch gather interested people = to > work on it ? >=20 > Thoughts ? >=20 >=20 > On Tue, Jan 8, 2013 at 9:21 PM, John Burwell wrote: >=20 > > Edison, > > > > Cool. Sorry for the mini-freak out. I also posted my design thoughts = to > > the "new storage framework update" thread started a little bit back. > > > > Thanks, > > -John > > > > On Jan 8, 2013, at 3:07 PM, Edison Su wrote: > > > > > Yes, there is no immediate change to s3-backed storage code on master > > branch after javelin is merged into master. As I haven't glue the new > > storage code on javelin branch with storage related api calls yet, so a= ll > > the existing storage code on master will/should work as it is. > > > After the merge, we can decide when to use the new storage framework > > code. I think all we agree on that the storage code needs to be refacto= red, > > and if then we agree on how to do it, that will be the time we can swit= ch > > to new storage code. > > > > > >> -----Original Message----- > > >> From: John Burwell [mailto:jburwell@basho.com] > > >> Sent: Tuesday, January 08, 2013 10:44 AM > > >> To: cloudstack-dev@incubator.apache.org > > >> Subject: Re: [MERGE] Merge Javelin branch into master > > >> > > >> Edison, > > >> > > >> So the current changes for S3-backed Secondary Storage will not be > > impacted > > >> by the Javelin's new storage architecture? > > >> > > >> Thanks, > > >> -John > > >> > > >> On Jan 8, 2013, at 1:21 PM, Edison Su wrote: > > >> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: John Burwell [mailto:jburwell@basho.com] > > >>>> Sent: Tuesday, January 08, 2013 9:13 AM > > >>>> To: cloudstack-dev@incubator.apache.org > > >>>> Subject: Re: [MERGE] Merge Javelin branch into master > > >>>> > > >>>> All, > > >>>> > > >>>> Will this merge be pre or post 4.1.0? I am concerned regarding th= e > > >>>> S3-backed > > >>> > > >>> Plan before 4.1.0. > > >>> > > >>>> Secondary Storage feature. Looking at this branch, the work done = to > > >>>> support > > >>>> S3 does not appear to compatible with the new storage architecture= , > > >>>> and I don't think there is enough time before 31 Jan 2013 to > > >>>> retrofit. I also have > > >>> > > >>> The existing storage code on master will not be changed, as the mos= t > > of our > > >> changes on javelin branch are in the fresh new maven projects. > > >>> > > >>>> design concerns which I raise on a separate thread. > > >>> > > >>> > > >>> I'd like to know your comments on the design. > > >>> > > >>>> > > >>>> Thanks, > > >>>> -John > > >>>> > > >>>> On Jan 8, 2013, at 12:08 PM, Alex Huang > > wrote: > > >>>> > > >>>>>> The problem that Howie is talking about is that none of our > > >>>>>> projects are structured in the "standard" maven layout. This is= n't > > >>>>>> just a test source issue. > > >>>>>> > > >>>>> I'm saying maven have a way to accommodate for that by specifying > > >>>>> exactly > > >>>> where the directory should be in the pom.xml. > > >>>>> > > >>>>> Like I said though, I don't know why it doesn't follow standard > > layout. > > >>>> Maybe it was just easier to do the maven conversion this way? I > > >>>> think all the directories in javelin has follow the current layout= in > > >>>> 4.0 as well. We can make all of the javelin directories follow th= e > > >>>> standard if there was no clear call on how to layout the structure= s > > >> originally. > > >>>>> > > >>>>> --Alex > > >>> > > > > > > > >=20 >=20 > -- > Thanks > - Mohammad Nour > ---- > "Life is like riding a bicycle. To keep your balance you must keep moving= " > - Albert Einstein