+1 for the dislike :P but users will tell us if they like having 12
scripts
laying around.
They are under a ./cordova folder. They are not laying around. No one
has to use them if they don't want to.
On Tue, Apr 9, 2013 at 11:38 AM, Joe Bowser bows...@gmail.com wrote:
Augh! This actually made
FYI issues for all of these scripts have been filed.
On 3/28/13 1:31 PM, Michael Brooks mich...@michaelbrooks.ca wrote:
Fil, great work on the wiki document. Below are some feedback points.
`build`
...
What happens when a user specifies both --debug and --release?
I'm happy as long as we
Augh! This actually made it past the mailing list. :(
I hate this idea for the emulators and devices, because this is a set
of extremely complex script that has next to zero payoff for our
users. I really wish I paid more attention to this thread earlier on,
because I really don't like these
+1 for the dislike :P but users will tell us if they like having 12 scripts
laying around.
On Tue, Apr 9, 2013 at 11:38 AM, Joe Bowser bows...@gmail.com wrote:
Augh! This actually made it past the mailing list. :(
I hate this idea for the emulators and devices, because this is a set
of
Augh! This actually made it past the mailing list. :(
...
+1 for the dislike :P but users will tell us if they like having 12 scripts
laying around.
They are only assigned issues. If you guys have concerns, bring them up.
There is little point in committing to work if it isn't valuable to
Or it can just fail and ask users to build with the appropriate flag first.
I mean that is if we're following the 'one script does only one thing' idea.
On Tue, Apr 9, 2013 at 12:54 PM, Michael Brooks mich...@michaelbrooks.cawrote:
Augh! This actually made it past the mailing list. :(
For windows phone I just have a deploy.js (jscript) that handles all of the
run and install commands.
Usage: [ --device | --emulator | --target=id ] [ --debug | --release |
--nobuild ]
In the case that just `run` is called, the script will follow the `run`
specification as documented in the wiki
On Tue, Apr 9, 2013 at 2:44 PM, Benn Mapes benn.ma...@gmail.com wrote:
It wouldn't be hard to error out instead of giving a warning message about
what the tool is doing BUT I think it would be less frustrating for users
of the tool if it just did what they were trying to do and used defaults
Well in that case I would recommend just calling the tool with the
specifications that you want. That way you would get the desired behavior.
The WARNING message gives you all the flags you didn't specify so if it's
not doing what you want, just run it again and specify what you want.
For new
TL;DR I agree with all your points Mike. I'll update the doc shortly with
your suggestions.
Assuming there are no other qualms, I'll slate this stuff for 2.7?
Specific comments in-line below.
`build`
...
What happens when a user specifies both --debug and --release?
I'm happy as long as
Fil, great work on the wiki document. Below are some feedback points.
`build`
...
What happens when a user specifies both --debug and --release?
I'm happy as long as we decide on what happens. For the sake of ease, I
think it would be better to just fail.
This brings up the question of
OK, I've done some rehash of the proposal and put it up on the wiki:
http://wiki.apache.org/cordova/CommandLineToolingDesign
Please take a look and post back if you have questions, disagreement, want
to +1 it, etc.
At the top there is a generic multi-device flow that can solve a lot of
the
* log is only the Simulator
* build release/debug -- last one clobbers? depending on how the parsing is
implemented
On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj f...@adobe.com wrote:
OK, I've done some rehash of the proposal and put it up on the wiki:
Thanks Shaz, updated the wiki article.
On 3/26/13 4:07 PM, Shazron shaz...@gmail.com wrote:
* log is only the Simulator
* build release/debug -- last one clobbers? depending on how the parsing
is
implemented
On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj f...@adobe.com wrote:
OK, I've done some
To be absolutely clear, the above is NOT the motivation for changing this
stuff around. Cordova-cli needs consistency across platforms. This is the
motivation.
Yep, as long as we can guarantee that each script follows a predictable
input and output, I don't care how we implement it.
If you
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj f...@adobe.com wrote:
Hai gaiz!
Main contention between the two camps in this debate is four vs eight
scripts.. But Brian points out that refactoring smaller bits of
functionality into their own script allows us to have our cake and eat
Sounds good to me, though the prompting with a timeout seems a little
weird. If there is multiple I think it would be better just to prompt and
wait for a response
On Fri, Mar 22, 2013 at 3:03 PM, Brian LeRoux b...@brian.io wrote:
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj
I like this.
mw
On 3/22/13 6:03 PM, Brian LeRoux b...@brian.io wrote:
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj f...@adobe.com wrote:
Hai gaiz!
Main contention between the two camps in this debate is four vs eight
scripts.. But Brian points out that refactoring smaller bits of
+1
…however, currently the prompt is never shown when using the cli tools as they
are super-mega-secret-silent.
I only ever know that it wanted me to choose which emulator of the ones I have
available (android avd) when it times out and shows it as part of the error.
Something to keep in
+1
I think that would be a good place for the check_reqs script
On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj f...@adobe.com wrote:
One more addition: based on responses from the cordova-cli threads, it
looks like we'll also add a `check_reqs` script to each platform (perhaps
under
Actually, related to that and an outstanding request for cordova-cli to
accept a --verbose option: to add that option to all of these proposed
scripts.
On 3/22/13 3:55 PM, Tommy-Carlos Williams to...@devgeeks.org wrote:
+1
...however, currently the prompt is never shown when using the cli tools
from my BlackBerry 10 smartphone.
From: Benn Mapes
Sent: Friday, March 22, 2013 6:57 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Platform-level command line scripts ;)
+1
I think that would be a good place for the check_reqs script
On Fri, Mar 22, 2013 at 3:50 PM
that makes first entry inherent default).
Sent from my BlackBerry 10 smartphone.
From: Benn Mapes
Sent: Friday, March 22, 2013 6:57 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Platform-level command line scripts ;)
+1
I think that would be a good place
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Platform-level command line scripts ;)
+1
I think that would be a good place for the check_reqs script
On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj f...@adobe.com wrote:
One more addition: based
renaming stuff is easy.
Does it make sense to log without running? or does log also launch? where?
Sounds to me like logging is an option attached to a run command.
What is the point of cleaning if you're not going to build right after?
trying to free up hard drive space? anal much? or is clean
Ya tend to agree w/ the workflows you describe Jesse. Not at the
exlusion of discreet scripts however. We probably should have small
focused scripts and then compose the workflow scripts from them.
(Making it easier to test and compose new scripts and tooling.)
On Thu, Mar 21, 2013 at 12:07 AM,
On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks mich...@michaelbrooks.cawrote:
+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
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,
Yes... Why Not... That's part of the fun ... Isn't it?? [?]
On Thu, Mar 21, 2013 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
Who's four-command proposal is it? Anis' or Andrew's?
On 3/21/13 3: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
…or you can have functions do discrete actions like so:
https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bin/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb=HEAD
…instead of creating more inodes.
On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux
I knew you'd bring that up! We'll talk more tmrw.
On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI anis.ka...@gmail.com wrote:
…or you can have functions do discrete actions like so:
@cordova.apache.org
Subject: Platform-level command line scripts
Bringing this up once more, hopefully the last time :)
TL;DR: the behavior and naming of the platform-level scripts are still
not 100% lined up. I'd like to fix this and agree with you all on some
of the finer points surrounding this issue
am Parashuram, working for Microsoft Open
Technologies Inc.
-Original Message-
From: Filip Maj [mailto:f...@adobe.com]
Sent: Tuesday, March 19, 2013 3:42 PM
To: dev@cordova.apache.org
Subject: Platform-level command line scripts
Bringing this up once more, hopefully the last time
[mailto:f...@adobe.com]
Sent: Tuesday, March 19, 2013 3:42 PM
To: dev@cordova.apache.org
Subject: Platform-level command line scripts
Bringing this up once more, hopefully the last time :)
TL;DR: the behavior and naming of the platform-level scripts are still
not 100% lined up. I'd like
: Re: Platform-level command line scripts
I like the suggestions of having fewer commands. Actually, why not have
just one command? It would make for less copy/paste, and you'd only have to
use a single --help to see what you can do.
E.g.:
./cordova/cli.js build --profile=release
./cordova/cli.js
] on behalf of Andrew
Grieve [
agri...@chromium.org]
Sent: Wednesday, March 20, 2013 11:09 AM
To: dev
Subject: Re: Platform-level command line scripts
I like the suggestions of having fewer commands. Actually, why not have
just one command? It would make for less copy/paste, and you'd only
have
...@google.com [agri...@google.com] on behalf of Andrew
Grieve [
agri...@chromium.org]
Sent: Wednesday, March 20, 2013 11:09 AM
To: dev
Subject: Re: Platform-level command line scripts
I like the suggestions of having fewer commands. Actually, why not
have
just one command
On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes benn.ma...@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.
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 anis.ka...@gmail.com wrote:
On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes benn.ma...@gmail.com wrote:
I know
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
Sounds reasonable. I like small focused scripts but the argument of
duplicated code across different files is a good one.
On 3/20/13 7:36 PM, Andrew Grieve agri...@chromium.org wrote:
I really like Anis's suggestion of just four scripts. What's the
motivation
for having many scripts? Having
Bringing this up once more, hopefully the last time :)
TL;DR: the behavior and naming of the platform-level scripts are still not
100% lined up. I'd like to fix this and agree with you all on some of the
finer points surrounding this issue.
Benn Mapes, an intern at Adobe, has been working on
I agree with your easy wins.
As for the 'emulate' command I don't think it should exist and should be
replaced with 'run'. I thought we agreed on it in a previous thread. I
believe the way Android does it is the way to go.
The issue is to get it to work on iOS with Fruitstrap. Obviously we can't
I would also like to see iOS's release script changed.
Currently (as Fil said below) it compiles with the profile set to Release.
However, since it is still building targeting x86 (i.e.: the iOS Sim, not a
device) it is inconsistent with say the Android release script that actually
gets you a
The easy thing to do is download fruitstrap at runtime in the iOS
implementation, just like android + blackberry do for commons-codec and
any other required libs that we can't ship with cordova.
I still see value in having an emulate command that will RUN an emulator.
I would like to hear more
I agree with Anis, and your easy wins Fil!
emulate is confusing, unless emulate is 'ripple only!'
I think run should take a parameter which specifies where it should run,
defaulting to an attached device perhaps.
The cordova-deploy tool for Windows Phone 8 and Windows Phone 7 ( same API,
I agree with the BlackBerry scripts must do. Most of the BlackBerry stuff
should be pretty simple. If you took all the existing ant commands and
what's in the cordova scripts already, you're most of the way there.
However, I'm not sure what log would look like. I think there's a way to
ssh your
: Tuesday, March 19, 2013 3:42 PM
To: dev@cordova.apache.org
Subject: Platform-level command line scripts
Bringing this up once more, hopefully the last time :)
TL;DR: the behavior and naming of the platform-level scripts are still not 100%
lined up. I'd like to fix this and agree with you all
49 matches
Mail list logo
