cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Grebnov (Akvelon)" <>
Subject RE: Cordova --list option implementation
Date Tue, 06 Jan 2015 09:07:07 GMT
In case of 1a "Ignoring unknown flags" approach I would also warn for each unknown parameter.

-----Original Message-----
From: Parashuram N (MS OPEN TECH) [] 
Sent: Tuesday, January 6, 2015 6:22 AM
To: dev
Subject: Cordova --list option implementation

Forking from Re: [DISCUSS] Tools Release to continue discussion.

+1 to Andrew suggestion that adding a top level command just for listing
targets would be an overkill. Also, people usually want to see the supported targets when
they run, so it makes sense to expose it closer to where it gets used.

If we decide that cordova target add could be used to create new targets, that could be a
separate top level command, can `cordova run <list` could be the alias for `cordova target
platform list` command (though I am not a fan of aliasing commands).

Josh, is your concern that <list throws an error in case of blackberry? We could fix that
by either

1a- Ignoring unknown flags like other platforms - and document the ignoring part as the default
behavior 1b - or change other platforms to throw error on unsupported flags. In this case,
<list would do the check to see if <list is implemented first.

2. Implement <list for blackberry, thereby not having error on any platform. We could then
have a separate discussion about what happens when a flag is not supported by a platform.

It would be great if we can let users use the <list functionality with minimal disruption
to any platform.

On 1/5/15, 6:43 PM, "Andrew Grieve" <> wrote:

>Josh - thanks for pointing out that the change isn't working as intended.
>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:
>ERROR : Run option '--list' not recognized.
>ERROR running one or more of the platforms: Error:
>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"
>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 <> wrote:
>> Murat Sutunc wrote:
>> >1) When provided with an unknown extra parameter, such as --list in
>> >case, all the platforms ignore it. This looks like the expected
>> >as there are several issues in Jira related to it. (ex. See bug
>>CB-6676 -
>> >
>> >%20text%20~%20%22ignore%20parameter%22). Exit code 1 on Blackberry
>> >like a bug.
>> * 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
>> >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
>> >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
>> >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  
>> >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 

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message