Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-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 EAB88F096 for ; Thu, 21 Mar 2013 23:01:29 +0000 (UTC) Received: (qmail 51111 invoked by uid 500); 21 Mar 2013 23:01:29 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 51092 invoked by uid 500); 21 Mar 2013 23:01:29 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 51084 invoked by uid 99); 21 Mar 2013 23:01:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Mar 2013 23:01:29 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of shirleya.fui26@gmail.com designates 209.85.220.175 as permitted sender) Received: from [209.85.220.175] (HELO mail-vc0-f175.google.com) (209.85.220.175) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Mar 2013 23:01:25 +0000 Received: by mail-vc0-f175.google.com with SMTP id hf12so2741220vcb.20 for ; Thu, 21 Mar 2013 16:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:x-goomoji-body:date :message-id:subject:from:to:content-type; bh=754W31c3/nm/U7+yLeFjikY9zxLvyFEqOrkITahVPyo=; b=MK8m+pKaqvxgudCcVWT7LE47ZMCYQ46empTn9weBr3mjoIn70y9B3UeuMedyoDzXpI DBCcnrIP4uAD6dZAFRfn9SKTZxF6ltE8/9/dcV4J+kje58UtFeYQS6fGBE6nGmtNOm2N 2dUcjSikrtubqmD9JN1NVmer0OmU0SE2nkzHHuQuqyX6AsPfoIZv5deFnFl0jYqfbGXZ rb9Y09Hz5/Ih1yS6aS6A1bB5LnrTQbJJX55DPaclqUTfx6TiOpr7tFsv3AO38FQ2emWK kK3SU2qAfzUPb5Wre1b2JuN9zsh85ig6M/yNIo35TrNq4XbGLnAEVr720sIbUboh+pje dmvw== MIME-Version: 1.0 X-Received: by 10.220.88.145 with SMTP id a17mr15805398vcm.66.1363906864882; Thu, 21 Mar 2013 16:01:04 -0700 (PDT) Received: by 10.59.3.232 with HTTP; Thu, 21 Mar 2013 16:01:04 -0700 (PDT) In-Reply-To: References: X-Goomoji-Body: true Date: Thu, 21 Mar 2013 19:01:04 -0400 Message-ID: Subject: Re: Platform-level command line scripts From: Shirley Adams To: dev@cordova.apache.org Content-Type: multipart/related; boundary=047d7b3a8f143072f504d8775091 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b3a8f143072f504d8775091 Content-Type: multipart/alternative; boundary=047d7b3a8f143072f304d8775090 --047d7b3a8f143072f304d8775090 Content-Type: text/plain; charset=ISO-8859-1 Yes... Why Not... That's part of the fun ... Isn't it?? [?] On Thu, Mar 21, 2013 at 6:14 PM, Brian LeRoux wrote: > I think we can have our cake and eat it too. We should have four high > level commands. Those commands can shell to lower level discreetly > testable commands. The end user will never know the difference. The > developers win the tight abstraction we seek. > > Make sense? > > On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI wrote: > > On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks < > michael@michaelbrooks.ca>wrote: > > > >> +1 Fil's outlined design. > >> > >> I'm still not convinced of what Anis and Andrew are in favour of. Having > >> each script do more will make it more difficult for common results > across > >> all platforms. > >> > >> I really like Anis's suggestion of just four scripts. What's the > motivation > >> > for having many scripts? Having fewer will dramatically reduce copy & > >> paste > >> > bugs. It will also aid discoverability (since you'll get --help > instead > >> of > >> > just "ls" and infer from the name what they do). > >> > >> > >> The motivation for having many scripts is that there is a single entry > >> point for a single action. Each action is discrete. Either a platform > >> supports `deploy-emulator` or doesn't. If we have a single `run` > >> entry-point, it becomes confusing whether a platform supports all > >> requirements of the `run` action. > >> > >> I feel the code repetition is also a weak argument. We are defining > >> entry-point scripts. You can refactor out the common routines (e.g. > build) > >> into a helper script that can be invoked by multiple scripts. As far as > I > >> know, this is possible in bash, batch, and Windows Script Hosting. > >> > > > > I guess this topic will need a vote to follow the Apache Way. We've been > > talking about/implementing/changing these scripts for a long time and we > > can't seem to come to a complete agreement. > > > > > >> > >> ripple should be a separate option and not a separate command in my > >> > opinion. To simplify things and if everyone agrees we can ignore the > >> `run` > >> > command flow above and launch ripple by default and ask users to > specify > >> > options if they want to deploy and run to a particular > device/emulator. > >> > >> > >> I feel Ripple has no place in the platform-specific scripts. I love > Ripple, > >> but Ripple belongs is a higher-level tool such as Cordova CLI. The > >> platform-specific scripts are meant to deal with platform-specific > >> functions. > >> > > > > I don't have a strong opinion on this. So I could agree with you that > this > > Ripple could be a higher-level tool. > > > > > >> > >> Michael > >> > >> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes > wrote: > >> > >> > I liked the idea you mentioned earlier with having one wrapper script, > >> > that way there is one entry point for the given commands for the > needed > >> > functionality. Then it doesn't matter what underlying scripts > actually do > >> > the work. > >> > > >> > Then our only focus would be on the commands and not so much the name > of > >> > the scripts. > >> > > >> > > >> > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > >> > wrote: > >> > > >> > > I really like Anis's suggestion of just four scripts. What's the > >> > motivation > >> > > for having many scripts? Having fewer will dramatically reduce copy > & > >> > paste > >> > > bugs. It will also aid discoverability (since you'll get --help > instead > >> > of > >> > > just "ls" and infer from the name what they do). > >> > > > >> > > > >> > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > >> > > > >> > > > Ya ya ya we're all on agreement on this specific issue. The > >> underlying > >> > > > platform scripts can be used regardless of whether you're using > >> > > > cordova-cli or not. > >> > > > > >> > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > >> > > > > >> > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes < > benn.mapes@gmail.com> > >> > > wrote: > >> > > > > > >> > > > >> I know that sounds > >> > > > >> like a lot > >> > > > >> of scripts but we're building them for the cordova-cli to use, > >> so i > >> > > > >>like > >> > > > >> the idea of breaking > >> > > > >> them out so each script does a *very specific* task with as > >> > > > >>little-to-no > >> > > > >> > >> > > > > > >> > > > >No we're not. cordova-cli is a cool tool that people can use but > it > >> > > should > >> > > > >not be the only way of building Cordova apps in my opinion. > >> > > > > >> > > > > >> > > > >> > > >> > --047d7b3a8f143072f304d8775090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes... Why Not... That's part of the fun ... Isn't it??=A0

On Thu, Mar 21, 201= 3 at 6:14 PM, Brian LeRoux <b@brian.io> wrote:
I think we can have our cake and eat it too.= We should have four high
level commands. Those commands can shell to lower level discreetly
testable commands. The end user will never know the difference. The
developers win the tight abstraction we seek.

Make sense?

On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks <michael@michaelbrooks.ca>wrote:
>
>> +1 Fil's outlined design.
>>
>> I'm still not convinced of what Anis and Andrew are in favour = of. Having
>> each script do more will make it more difficult for common results= across
>> all platforms.
>>
>> I really like Anis's suggestion of just four scripts. What'= ;s the motivation
>> > for having many scripts? Having fewer will dramatically reduc= e copy &
>> paste
>> > bugs. It will also aid discoverability (since you'll get = --help instead
>> of
>> > just "ls" and infer from the name what they do). >>
>>
>> The motivation for having many scripts is that there is a single e= ntry
>> point for a single action. Each action is discrete. Either a platf= orm
>> supports `deploy-emulator` or doesn't. If we have a single `ru= n`
>> entry-point, it becomes confusing whether a platform supports all<= br> >> requirements of the `run` action.
>>
>> I feel the code repetition is also a weak argument. We are definin= g
>> entry-point scripts. You can refactor out the common routines (e.g= . build)
>> into a helper script that can be invoked by multiple scripts. As f= ar as I
>> know, this is possible in bash, batch, and Windows Script Hosting.=
>>
>
> I guess this topic will need a vote to follow the Apache Way. We'v= e been
> talking about/implementing/changing these scripts for a long time and = we
> can't seem to come to a complete agreement.
>
>
>>
>> ripple should be a separate option and not a separate command in m= y
>> > opinion. To simplify things and if everyone agrees we can ign= ore the
>> `run`
>> > command flow above and launch ripple by default and ask users= to specify
>> > options if they want to deploy and run to a particular device= /emulator.
>>
>>
>> I feel Ripple has no place in the platform-specific scripts. I lov= e Ripple,
>> but Ripple belongs is a higher-level tool such as Cordova CLI. The=
>> platform-specific scripts are meant to deal with platform-specific=
>> functions.
>>
>
> I don't have a strong opinion on this. So I could agree with you t= hat this
> Ripple could be a higher-level tool.
>
>
>>
>> Michael
>>
>> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes <benn.mapes@gmail.com> wrote:
>>
>> > I liked the idea you mentioned earlier with having one wrappe= r script,
>> > that way there is one entry point for the given commands for = the needed
>> > functionality. Then it doesn't matter what underlying scr= ipts actually do
>> > the work.
>> >
>> > Then our only focus would be on the commands and not so much = the name of
>> > the scripts.
>> >
>> >
>> > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve <agrieve@chromium.org>
>> > wrote:
>> >
>> > > I really like Anis's suggestion of just four scripts= . What's the
>> > motivation
>> > > for having many scripts? Having fewer will dramatically = reduce copy &
>> > paste
>> > > bugs. It will also aid discoverability (since you'll= get --help instead
>> > of
>> > > just "ls" and infer from the name what they do= ).
>> > >
>> > >
>> > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj <fil@adobe.com> wrote:
>> > >
>> > > > Ya ya ya we're all on agreement on this specifi= c issue. The
>> underlying
>> > > > platform scripts can be used regardless of whether = you're using
>> > > > cordova-cli or not.
>> > > >
>> > > > On 3/20/13 3:51 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>> > > >
>> > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes <= ;benn.mapes@gmail.com>
>> > > wrote:
>> > > > >
>> > > > >> I know that sounds
>> > > > >> like a lot
>> > > > >> of scripts but we're building them for= the cordova-cli to use,
>> =A0so i
>> > > > >>like
>> > > > >> the idea of breaking
>> > > > >> =A0them out so each script does a *very sp= ecific* task with as
>> > > > >>little-to-no
>> > > > >>
>> > > > >
>> > > > >No we're not. cordova-cli is a cool tool th= at people can use but it
>> > > should
>> > > > >not be the only way of building Cordova apps in= my opinion.
>> > > >
>> > > >
>> > >
>> >
>>

--047d7b3a8f143072f304d8775090-- --047d7b3a8f143072f504d8775091--