Ok just to get this straight, we would like to see these scripts in the cordova directory of a Cordova project.
*build* - compiles the project so that it can be deployed (possible flags are debug and release?) *clean* - removes all generated files (are these just the project specific files or the ones generated for the platform as well, i.e CordovaDeploy.exe for windows) *log *- logs device output (not supported yet for windows) *release* - Is this just the equivalent of `build` but in release mode? maybe you can just make this a flag in the build script? *run *- This would handle deploying the already built application to a device or emulator of the users choosing (do we want to prompt for this or use flags to decide?) *emulate* - I like jesse's suggestion that this should be used for *ripple only* * * Cheers, ~Benn On Tue, Mar 19, 2013 at 4:48 PM, Jesse <purplecabb...@gmail.com> wrote: > I agree with Anis, and your easy wins Fil! > > emulate is confusing, unless emulate is 'ripple only!' > > I think run should take a parameter which specifies where it should run, > defaulting to an attached device perhaps. > > The cordova-deploy tool for Windows Phone 8 and Windows Phone 7 ( same API, > different implementations/requirements/libraries ) has a simple interface > where you can call it with -devices and it will simply list targets [1] > > > In this case, the deploy tool is not going to build anything, as it is > specifically *just* a deploy tool, but ultimately on WP7+8 this is what the > cl tools will use anyway. > An approach like this allows you to target multiple emulators ( WP8 has 7 > different emulators ) > > > [1] > > https://github.com/purplecabbage/cordova-wp8/blob/master/tooling/CordovaDeploy/CordovaDeploy/Program.cs#L45 > > @purplecabbage > risingj.com > > > On Tue, Mar 19, 2013 at 4:32 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > > > I agree with your easy wins. > > > > As for the 'emulate' command I don't think it should exist and should be > > replaced with 'run'. I thought we agreed on it in a previous thread. I > > believe the way Android does it is the way to go. > > > > The issue is to get it to work on iOS with Fruitstrap. Obviously we can't > > ship FruitStrap with Cordova but we can script it to download it when we > > use the "run" command. > > > > Don't know anything about BlackBerry but I want to say that there should > be > > a way to detected connected devices without prompting the user, yes ? > > > > -a > > > > > > On Tue, Mar 19, 2013 at 3:42 PM, Filip Maj <f...@adobe.com> wrote: > > > > > 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 > > > > > > > > >
