I agree with the BlackBerry scripts must do. Most of the BlackBerry stuff should be pretty simple. If you took all the existing ant commands and what's in the cordova scripts already, you're most of the way there.
However, I'm not sure what log would look like. I think there's a way to ssh your way into the BB10 and get access to the device log which could be pretty useful. However, I haven't been able to do it on my dev alpha (was locked out via file permissions), but maybe the z10 is able to??? On 19 March 2013 17:25, Benn Mapes <benn.ma...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > -- Timothy Kim
