cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Platform-level command line scripts
Date Wed, 20 Mar 2013 15:09:04 GMT
I like the suggestions of having fewer commands. Actually, why not have
just one command? It would make for less copy/paste, and you'd only have to
use a single --help to see what you can do.

E.g.:

./cordova/cli.js build --profile=release
./cordova/cli.js build --profile=debug
./cordova/cli.js clean
./cordova/cli.js package  // For app store
./cordova/cli.js log
./cordova/cli.js run --target=DEVICE_ID
./cordova/cli.js run --target=EMULATOR_ID
./cordova/cli.js run --target=ripple
./cordova/cli.js run --target=emulator
./cordova/cli.js run --target=emulator





On Wed, Mar 20, 2013 at 6:19 AM, Brian LeRoux <b@brian.io> wrote:

> Fil: yes I like the easy wins you describe.
>
> Anis: agree on harder wins. The `emulate` cmd should require a
> parameter and only launch platform emulators.  The `run` cmd should
> default to Ripple, and while we're in there we should kill the serve
> command. Also agree, we should do a download to Fruitstrap from one of
> our forks (to be safe).
>
> Tommy: would be awesome to get your help on the `release` cmd for iOS.
>
> Jesse: agree about cordova-deploy tool should just deploy. (Only I
> think we should rename it to `emulate` and have it require a
> parameter.)
>
> Mapes: we hate the Bruins ok buddy? Get over it. Also: `build` cmd is
> for debug builds and `release` cmd is for doing release builds as you
> intuited. I think you got `run` and `emulate` mixed up but the spirit
> was correct.
>
> Tim/Bryan: can we kick up a fresh thread on the BB10 business? It
> would be nice to get that in but I think those queries got lost in
> this deluge.
>
> Axe! (Parashuram's online crime fighting persona is axemclion): thanks
> for saying hi, we'd love the help yo!
>
>
> On Wed, Mar 20, 2013 at 1:14 AM, Jesse MacFadyen
> <purplecabbage@gmail.com> wrote:
> > Welcome Parashuram!
> > Happy to have some help. Benn has been working on most of this, and I
> > have created the deploy tools for wp7 and wp8, so reach out if you
> > need guidance or anything.
> >
> > Cheers,
> >   Jesse
> >
> > Sent from my iPhone5
> >
> > On 2013-03-19, at 10:24 PM, "Parashuram Narasimhan (MS OPEN TECH)"
> > <panarasi@microsoft.com> wrote:
> >
> > Hi,
> >
> > I could offer to start helping on the Windows Phone side of things.
> >
> > P.S: This is my first email to the group, and I think I should
> > introduce myself - I am Parashuram, working for Microsoft Open
> > Technologies Inc.
> >
> > -----Original Message-----
> > From: Filip Maj [mailto:fil@adobe.com]
> > Sent: Tuesday, March 19, 2013 3:42 PM
> > To: dev@cordova.apache.org
> > Subject: Platform-level command line scripts
> >
> > 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