>+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 wrote:
>
>> Augh! This actually made it past
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 user
On Tue, Apr 9, 2013 at 2:44 PM, Benn Mapes 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
> for the things th
For windows phone I just have a deploy.js (jscript) that handles all of the
run and install commands.
Usage: [ --device | --emulator | --target= ] [ --debug | --release |
--nobuild ]
In the case that just `run` is called, the script will follow the `run`
specification as documented in the wiki (ex
If there is any chance of mutual exclusivity, an error should be raised.
Otherwise the user has no idea which one happened. For building, I could see
doing both the debug and release version. But for deploying/running, I would
argue the intent is for only one at a time? (At least to me.)
_
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 wrote:
> >
> > Augh! This actually made it past the mailing list. :(
>
> ...
>
> > +1 for the
>
> 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
+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 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 extremely complex
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 scri
FYI issues for all of these scripts have been filed.
On 3/28/13 1:31 PM, "Michael Brooks" 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 decide on w
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 l
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 exi
Thanks Shaz, updated the wiki article.
On 3/26/13 4:07 PM, "Shazron" 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 wrote:
>
>> OK, I've done some rehash of the propos
* 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 wrote:
> OK, I've done some rehash of the proposal and put it up on the wiki:
> http://wiki.apache.org/cordova/CommandLineToolingDesign
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 consis
>
> 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 y
>Hopefully, next time we will change/update these things it will be for a
>real reason (such as SDK tools updates etc...) and not because we think
>that there might be a better implementation in C#.
To be absolutely clear, the above is NOT the motivation for changing this
stuff around. Cordova-cl
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 scr
pose 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 ;)
>
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
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" wrote:
>+1
>
>...however, currently the prompt is never shown when using the cli tools as
>they ar
+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 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 /cordova/lib)
>
> On 3/2
+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 mind
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 /cordova/lib)
On 3/22/13 3:10 PM, "Michael Wolf" wrote:
>I like this.
>
>mw
>
>On 3/22/13 6:03 PM, "Brian LeRoux" wrote:
>
>>YES. Do it.
>>
>>On
I like this.
mw
On 3/22/13 6:03 PM, "Brian LeRoux" wrote:
>YES. Do it.
>
>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj 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
>> functiona
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 wrote:
> YES. Do it.
>
> On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote:
> > H
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj 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 it
> to
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 it
too". This, in turn, results in four + (a subset of the 8) = 10 scripts in
to
I knew you'd bring that up! We'll talk more tmrw.
On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote:
> …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=1945a4c45f835a6eab3836c4154e518
…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 wrote:
> You could make more scripts as helper scripts, but I still think that it
> will be confusing if a user types "ls" and sees a large number of scripts,
> having to guess what each of them does.
Put them in a subdir called ./lib and be done w/ it.
> I don't think having more scripts will make it
On Thu, Mar 21, 2013 at 6:51 PM, Filip Maj wrote:
> It looks like we are split between Reductionist (four commands and/or less
> commands) and.. The opposite.. Of reductionists? Antireductionist?
>
> Two points I think supporting the antireductionist argument:
>
> 1. number of scripts being an is
Who's four-command proposal is it? Anis' or Andrew's?
On 3/21/13 3: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 differen
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 nev
It looks like we are split between Reductionist (four commands and/or less
commands) and.. The opposite.. Of reductionists? Antireductionist?
Two points I think supporting the antireductionist argument:
1. number of scripts being an issue because of possible bug repetition
across scripts is put t
+1
On 22/03/2013, at 9:14 AM, 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 abstrac
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, A
On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks 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 f
+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
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,
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 ju
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 o
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" wrote:
>I really like Anis's suggestion of just four scripts. What's the
>motivation
>for having many scripts? Having fewer will dramatica
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
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 wrote:
>
>> I know that sounds
>> like a lot
>> of scri
On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes 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 coo
cit nature is
> > >critical. A script must do one thing and only one thing. If we deviate
> > >from
> > >this, then platform-specific scripts will likely act different for each
> > >platform.
> > >
> > >Michael
> > >
> > &g
Wallis
> >wrote:
> >
> >> Deploy vs. Emulate: Deploy could be used to deploy to anything,
> >>emulator,
> >> ripple, simulator, or actual device. I think perhaps deploy is the
> >>right
> >> terminology in this regard than emulate?
> >>
> >> I ag
valuable to standardize arguments as
>> well, in so far as those those that are common across platforms.
>> --
>>
>> Ken Wallis
>>
>> Product Manager WebWorks
>>
>> BlackBerry
>>
>> 289-261-4369
>>
>> ___
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
: 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/c
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 build --profile=debug
./cordova/cli.js cl
While we're discussing the platform level scripts, should we also attempt
to standardize the arguments that can be passed in as well?
On 13-03-20 6:19 AM, "Brian LeRoux" wrote:
>Fil: yes I like the easy wins you describe.
>
>Anis: agree on harder wins. The `emulate` cmd should require a
>paramet
Fil: yes I like the easy wins you describe.
Anis: agree on harder wins. The `emulate` cmd should require a
parameter and only launch platform emulators. The `run` cmd should
default to Ripple, and while we're in there we should kill the serve
command. Also agree, we should do a download to Fruits
Welcome Parashuram!
Happy to have some help. Benn has been working on most of this, and I
have created the deploy tools for wp7 and wp8, so reach out if you
need guidance or anything.
Cheers,
Jesse
Sent from my iPhone5
On 2013-03-19, at 10:24 PM, "Parashuram Narasimhan (MS OPEN TECH)"
wrote:
Hi,
I could offer to start helping on the Windows Phone side of things.
P.S: This is my first email to the group, and I think I should introduce myself
- I am Parashuram, working for Microsoft Open Technologies Inc.
-Original Message-
From: Filip Maj [mailto:f...@adobe.com]
Sent: Tue
We've been looking into the platform scripts for BB recently. Hopefully
I'll have some code to share soon.
Here is what we are thinking:
- build - should create and deploy debug token by default rather than
signing. We'd also like this to compile any native plugins.
- release - just calls build wi
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 wa
Ok just to get this straight, we would like to see these scripts in the
cordova directory of a Cordova project.
*build* - compiles the project so that it can be deployed (possible flags
are debug and release?)
*clean* - removes all generated files (are these just the project specific
files or the
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,
differe
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 o
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
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
63 matches
Mail list logo
