I counted...there are 8 commands in total in your thread. With all the disparities across platforms, it's going to be hard to come to an exact match. If we want to sort this out cleanly and easily, I believe we should as few commands as possible.
I think there should not be more than 4 (build, clean, log, run) and potentially adding options for the rest. * `build`: Compiles & packages. Add an option for release/debug mode. Default should be debug. * `clean`: Obvious. * `log`: tail -f logs. Again add an option if you want to filter which device/emulator you want to log otherwise default to whatever filter the SDK command picks (if present). * `run`: THIS is the tricky one. Should just deploy to device/emulator! You can also add an option to specify which emulator/device/ripple. Should always be preceded by `build` because you obviously can't run something that is not built ;) For the `run` command I believe the default (& complicated :) flow should be: If device(s) connected: * Pick device (ignore emulators). * Prompt, timeout and pick first one (5 to 10 seconds) if multiple devices are connected (ignore emulators). If device(s) not connected: * Emulator if it is running * Prompt, timeout and pick first one (5 to 10 seconds) if multiple emulators are running. * Start emulator. If you have multiple ones set up (Android's case), prompt, timeout and launch first one (5 to 10 seconds). ripple should be a separate option and not a separate command in my opinion. To simplify things and if everyone agrees we can ignore the `run` command flow above and launch ripple by default and ask users to specify options if they want to deploy and run to a particular device/emulator. Totally agree on the "operation not supported" for every command that is not supported on a specific platform but the command should always be present. First step would be to have the exact same commands on all platforms (no more, no less and we're not there as of this writing). Second step would be to get them to do the same actions as much as possible (this will be difficult because of all the disparities: no logging on Windows... and requirements: FruitStrap etc..). -a On Wed, Mar 20, 2013 at 1:26 PM, Filip Maj <f...@adobe.com> wrote: > Thanks everyone for chiming in, really appreciate this. > > I'm of the same opinion as Michael. The current confusion started because > of (arguably) ambiguous terminology used for script names and no explicit > behavior for each listed out. My goal is to arrive at a consensus on the > naming and behavior of various scripts. > > The objectives for the scripts should be: > - each script is unambiguously named and does a single, explicit task > (that we formalize in this thread) > - all platforms implement each script, with a default of exiting with > non-zero code and logging out "unsupported" if the implementation is not > possible or not done at this time > > Based on everyone's responses, here's my first crack at the scripts (with > questions under each). Also note that I'm open to having some of this > functionality under one command with specific flags, like deployment and > compilation. I just want to guide the discussion towards agreement. > > 1. `clean`: rm -rf's any compilation artifacts. > > 2. `log`: streams logs (console.log/error/dir) from a running cordova > application. > - say you have emulators running and multiple devices connected with > multiple cordova apps running. Which log do we stream? > > 3. `start-emulator` (was `emulate`): kicks up an emulator for the platform. > - some platforms allow for defining different emulators. How to handle > this? I.e. Which AVD to pick for android, which simulator for what iOS > version + model (if this is applicable for iOS), same for windows phone, > etc. > - do we want to include Ripple in the list for the above question, or > split this out into its own? I think I'd prefer `deploy-ripple` personally. > > 4. `deploy-device`, `deploy-emulator` (and possibly `deploy-ripple`). > Deploys a compiled app to the specified target. > - what if you have multiple devices/emulators running for the specified > platform? > - if there are no compiled bits, does this automatically invoke the > `compile` or `build` command (below)? > - if you run `deploy-emulator`, but don't have an emulator started, does > it run `start-emulator` ? > > 5. `compile-debug` or `compile-release` (or `build` instead of `compile`). > Runs the appropriate compilation. > > Discuss! > > > On 3/20/13 1:04 PM, "Michael Brooks" <mich...@michaelbrooks.ca> wrote: > > >I think this thread is starting to diverge from its purpose and step into > >the responsibilities of the Cordova CLI. > > > >Easy Wins > >> --------- > > > > > >Fil, I agree with your easy wins. Thanks for summarizing the current state > >of the platform-specific scripts. > > > >It would also be good to have a stubbed implemented of each script on each > >platform. For example, if a platform does not yet support "log" then it > >should still have a log script that echo's "logging is unuspported." This > >allows the Cordova CLI is "shell out" to the scripts without having to > >check whether the platform has indeed implemented something. > > > >Harder Wins > >> ----------- > > > > > >This deserves it's own thread. There seems to be a lot of confusion around > >the difference between and role of Cordova CLI commands and > >Platform-specific scripts. Some of the above replies are mixing or > >interchanging those terms. > > > >For platform-specific scripts, I believe a simple and explicit 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 > > > >On Wed, Mar 20, 2013 at 8:59 AM, Ken Wallis <kwal...@blackberry.com> > >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 agree with Jeff that it would be 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 > >> > >> ________________________________________ > >> From: agri...@google.com [agri...@google.com] on behalf of Andrew > >>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 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 > >> > > >> > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the > >> solicitor-client or other applicable privileges), or constitute > >>non-public > >> information. Any use of this information by anyone other than the > >>intended > >> recipient is prohibited. If you have received this transmission in > >>error, > >> please immediately reply to the sender and delete this information from > >> your system. Use, dissemination, distribution, or reproduction of this > >> transmission by unintended recipients is not authorized and may be > >>unlawful. > >> > >
