We've been looking into the platform scripts for BB recently. Hopefully I'll have some code to share soon.
Here is what we are thinking: - build - should create and deploy debug token by default rather than signing. We'd also like this to compile any native plugins. - release - just calls build with a release flag which code signs - clean - remove the generated files - run - deploys to device or simulator which is pre-configured - * target * - this would be an additional script to add/remove devices for the run command - log - I believe the blackberry-deploy tool can pull down the BB10 app logs. I'll double check that tomorrow. Questions: - Am I safe in my assumption that all platforms may define parameters differently as long as default actions are the same? - Should the build script call run after successful build as it does now? Thanks, Bryan On Tue, Mar 19, 2013 at 8:43 PM, Tim Kim <timki...@gmail.com> wrote: > 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 >
