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 clean ./cordova/cli.js package // For app store ./cordova/cli.js log ./cordova/cli.js run --target=DEVICE_ID ./cordova/cli.js run --target=EMULATOR_ID ./cordova/cli.js run --target=ripple ./cordova/cli.js run --target=emulator ./cordova/cli.js run --target=emulator On Wed, Mar 20, 2013 at 6:19 AM, Brian LeRoux <b...@brian.io> wrote: > 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 Fruitstrap from one of > our forks (to be safe). > > Tommy: would be awesome to get your help on the `release` cmd for iOS. > > Jesse: agree about cordova-deploy tool should just deploy. (Only I > think we should rename it to `emulate` and have it require a > parameter.) > > Mapes: we hate the Bruins ok buddy? Get over it. Also: `build` cmd is > for debug builds and `release` cmd is for doing release builds as you > intuited. I think you got `run` and `emulate` mixed up but the spirit > was correct. > > Tim/Bryan: can we kick up a fresh thread on the BB10 business? It > would be nice to get that in but I think those queries got lost in > this deluge. > > Axe! (Parashuram's online crime fighting persona is axemclion): thanks > for saying hi, we'd love the help yo! > > > On Wed, Mar 20, 2013 at 1:14 AM, Jesse MacFadyen > <purplecabb...@gmail.com> wrote: > > 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)" > > <panar...@microsoft.com> 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: 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 on some > > of the finer points surrounding this issue. > > > > Benn Mapes, an intern at Adobe, has been working on adding Windows > > Phone support to cordova-cli. It's been a bit of work, but the first > > step is to land command line scripts at the Windows Phone project > > level, which he is actively working on. With this happening, I want to > > make sure we have our base project-level CLI scripts sorted properly. > > > > Additionally, I've been seeing issues filed against the CLI with > > essentially users being confused as to why the behavior of "cordova > > build" > > vs "cordova emulate" on different platforms is different [1] [2]. > > > > The answer to all of this is that the project-level scripts have > > slightly different behavior. I've looked into what each of Android, > > iOS and BlackBerry (10) do and I've got a basic table sorted out > > (below). I would like to get to an agreement on naming and behavior > > for each, and ideally file issues to get as many of our platform > > implementations as possible to implement/tweak behavior so that we are > > consistent on this front. > > > > Scripts > > ------- > > > > - build > > - Android: equivalent of running `ant debug`, which simply compiles > > your app in debug mode > > - BB10: packages your app into a zip, runs `bbwp` on it, and > code-signs it > > - iOS: runs a compilation with xcodebuild with configuration set to > "Debug" > > - clean > > - Android: equivalent of running `ant clean`, which removes any > > build artifacts > > - BB10: does not exist > > - iOS: does not exist > > - log > > - Android: `adb logcat` > > - BB10: does not exist > > - iOS: `tail -f console.log` > > - release: > > - Android `ant release`, compiles with your actual signing key > > - BB10: NOPE > > - iOS: compiles with xcodebuild with configuration set to "Release" > > - run: > > - Android: runs on EITHER a connected device, or if no device, on a > > running emulator, or if no running emulator, launches an emulator (and > > if multiple emulator profiles exist, prompts user to pick one), then > > finally runs the app on it > > - BB10: asks user if there's a connected device. Then either > > launches a simulator + loads the app (if user says he/she has no > > connected device), or attempts runs a debug build of the app on a > > connected device > > - iOS: launches an emulator using ios-sim with the app > > - emulate: > > - Android: does not exist > > - BB10: does not exist > > - iOS: launches an emulator using ios-sim with the app > > > > Easy Wins > > --------- > > > > - build: BB10 should change current behaviour so that it doesn't code > > sign the package. > > - clean: add scripts for BB10 and iOS to support this (should be dead > simple). > > - release: BB10 should implement a script that runs a build + a > > code-sign on the built package. > > > > Harder Wins > > ----------- > > > > There's confusing behavior with run + emulate commands across platforms. > > IMO emulate should handle launching an emulator, and run should handle > > deployment, with an extra flag available for run command that > > specifies the deployment target (device or emulator, perhaps --device > > and --emulator). Also not entirely sure how Ripple fits in here but I > > would definitely like to see Ripple as the default emulator target. > > > > Lots to chew on here but I would highly appreciate some feedback! > > Renaming some of these commands is on the table too if anyone sees > > benefit there! > > > > [1] https://issues.apache.org/jira/browse/CB-2722 > > [2] https://issues.apache.org/jira/browse/CB-2724 >
