cordova-dev mailing list archives

Josh - thanks for pointing out that the change isn't working as intended. I
did some testing before merging, but didn't try the error conditions.
I've just reverted the one to CLI that enables the flag. Let's move forward
with releasing :)
Also noticed that if you have an older-than-master version of android
installed in your project, then you get:
$ cordova run --list
Running command:
/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/run
--list
ERROR : Run option '--list' not recognized.
ERROR running one or more of the platforms: Error:
/Users/agrieve/git/cordova/cordova-cli/foo/platforms/android/cordova/run:
Command failed with exit code 2
You may not have the required environment or OS to run this project
I actually do like the syntax of "cordova run --list", since the run
command is the thing that --target is relevant to anyways. Maybe
"--list-targets" would be more explicit? Adding "cordova target add" would
be overstepping I think. You can add Android emulator targets as well, but
us writing a wrapper for the logic would just make things more complicated
I think.
I do think that having cordova-lib look for the existence of
the list-emulator-images and list-devices scripts makes sense, and just
have it call them directly.
On Mon, Jan 5, 2015 at 5:29 PM, Josh Soref <jsoref@blackberry.com> wrote:
> Murat Sutunc wrote:
> >1) When provided with an unknown extra parameter, such as --list in this
> >case, all the platforms ignore it. This looks like the expected behavior
> >as there are several issues in Jira related to it. (ex. See bug CB-6676 -
> >
> https://issues.apache.org/jira/browse/CB-6676?jql=project%20%3D%20CB%20AND
> >%20text%20~%20%22ignore%20parameter%22). Exit code 1 on Blackberry seems
> >like a bug.
>
> https://wiki.apache.org/cordova/CommandLineToolingDesign#Errors
>
>
> * 1: not implemented / unsupported command
>
>
> I believe that what windows phone was doing was correct. And if someone is
> changing the contract, they failed to update the contract.
>
> >
> >2) Introducing 'target' as a top level option seems like a new proposal.
> >My thoughts were to avoid having a new top level command for listing
> >devices but I would like to hear others opinions on this as well. I also
> >think 'target' might not be the best choice of keyword here as it's
> >already part of 'run' and it's easy to get confused:
> > cordova run --target=FOO
> > cordova target --list
>
> Not --list, just plain "list". As in "cordova platform list", and "cordova
> plugin list", it's a commonly used idiom in cordova.
>
> >3) I don’t understand the 'cordova target add' command completely. Is it
> >an alias to 'cordova platform add'?
>
> No.
>
> For blackberry10 you can configure a "target" which is a name for a set of
> settings (including an ip address/dns name, whether it is a
> device/simulator, and a device password). You can then use run
> --target=foo.
>
> >4) 'Each platform should already support the list-* commands' is
> >currently not true. firefoxos, browser, Ubuntu don’t support it.
>
> Those platforms aren't complete, it's part of the contract, but we already
> have a good way of handling missing components of lib/ — if they don't
> exist (we can check for this), or aren't implemented (they return a
> standard value).
>
> The way you've implemented it with run, there's no way to look before you
> leap, which results in the failure that you introduced for blackberry10.
>