+1 to removing that specific commit and continuing with the release process. I have also forked this thread where we should continue the discussion (so as not to overload the DISCUSS thread).
On 1/5/15, 6:43 PM, "Andrew Grieve" <agri...@chromium.org> wrote: >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 <jso...@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%20AN >>D >> >%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. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
