cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benn Mapes <benn.ma...@gmail.com>
Subject Re: Platform-level command line scripts
Date Wed, 20 Mar 2013 00:25:40 GMT
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 <purplecabbage@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.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