cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Platform-level command line scripts
Date Tue, 19 Mar 2013 23:48:00 GMT
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.kadri@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 <fil@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message