For windows phone I just have a deploy.js (jscript) that handles all of the
run and install commands.
Usage: [ --device | --emulator | --target=<id> ] [ --debug | --release |
--nobuild ]

In the case that just `run` is called, the script will follow the `run`
specification as documented in the wiki (except it just deploys on the
emulator since we don't have a way of telling if a device is connected
*YET*) and informs the user with a WARNING message that it's default build
is in debug mode and it's deploying to the emulator.

In the case that only a deploy target is given, it will inform the user
with a WARNING message that it is defaulting to debug mode.

In the case that only a build argument is given it will again default to
deploying on an emulator with a warning message. For the --nobuild option
it just uses whatever .xap is already built.

It wouldn't be hard to error out instead of giving a warning message about
what the tool is doing BUT I think it would be less frustrating for users
of the tool if it just did what they were trying to do and used defaults
for the things they did not specify IMO.

~Benn


On Tue, Apr 9, 2013 at 2:14 PM, Kerri Shotts <kerrisho...@gmail.com> wrote:

> If there is any chance of mutual exclusivity, an error should be raised.
> Otherwise the user has no idea which one happened. For building, I could
> see doing both the debug and release version. But for deploying/running, I
> would argue the intent is for only one at a time? (At least to me.)
>
>
> ___________________________________
> Kerri Shotts
> photoKandy Studios, LLC
>
> On the Web: http://www.photokandy.com/
>
> Social Media:
>           Twitter: @photokandy, http://twitter.com/photokandy
>           Tumblr: http://photokandy.tumblr.com/
>           Github: https://github.com/kerrishotts
>                         https://github.com/organizations/photokandyStudios
>           CoderWall: https://coderwall.com/kerrishotts
>
> Apps on the Apple Store:
>
> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
>
> Books:
>
> http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book
>           http://www.packtpub.com/phonegap-social-app-development/book
>
>
> On Tuesday, April 9, 2013 at 3:23 PM, Anis KADRI wrote:
>
> > Or it can just fail and ask users to build with the appropriate flag
> first.
> > I mean that is if we're following the 'one script does only one thing'
> idea.
> >
> >
> > On Tue, Apr 9, 2013 at 12:54 PM, Michael Brooks <
> mich...@michaelbrooks.ca (mailto:mich...@michaelbrooks.ca)>wrote:
> >
> > > >
> > > > Augh! This actually made it past the mailing list. :(
> > >
> > > ...
> > >
> > > > +1 for the dislike :P but users will tell us if they like having 12
> > > scripts
> > > > laying around.
> > >
> > >
> > >
> > > They are only assigned issues. If you guys have concerns, bring them
> up.
> > > There is little point in committing to work if it isn't valuable to our
> > > users.
> > >
> > > On that note, Benn and I noticed a recent issue with the `run` command.
> > > Since `run` will implicitly build an application, it must accept the
> build
> > > mode flag `--debug` or `--release`. In other words, it should accept
> all
> > > parameters that `build` accepts and forward the valid ones to the
> `build`
> > > command. This should be true for any high-level command.
> > >
> > > Anyone have input on the `run` command? Once settled, we'll update the
> Wiki
> > > and issue details.
> > >
> > > Michael
> > >
> > >
> > > On Tue, Apr 9, 2013 at 11:47 AM, Anis KADRI <anis.ka...@gmail.com(mailto:
> anis.ka...@gmail.com)> wrote:
> > >
> > > > +1 for the dislike :P but users will tell us if they like having 12
> > > scripts
> > > > laying around.
> > > >
> > > >
> > > > On Tue, Apr 9, 2013 at 11:38 AM, Joe Bowser <bows...@gmail.com(mailto:
> bows...@gmail.com)> wrote:
> > > >
> > > > > Augh! This actually made it past the mailing list. :(
> > > > >
> > > > > I hate this idea for the emulators and devices, because this is a
> set
> > > > > of extremely complex script that has next to zero payoff for our
> > > > > users. I really wish I paid more attention to this thread earlier
> on,
> > > > > because I really don't like these scripts. I guess it's too late to
> > > > > vote a -1 against these, and I guess it's my fault for ignoring
> things
> > > > > I really dislike.
> > > > >
> > > > > Joe
> > > > >
> > > > > On Tue, Apr 9, 2013 at 7:46 AM, Filip Maj <f...@adobe.com (mailto:
> f...@adobe.com)> wrote:
> > > > > > FYI issues for all of these scripts have been filed.
> > > > > >
> > > > > > On 3/28/13 1:31 PM, "Michael Brooks" 
> > > > > > <mich...@michaelbrooks.ca(mailto:
> mich...@michaelbrooks.ca)>
> > > wrote:
> > > > > >
> > > > > > > Fil, great work on the wiki document. Below are some feedback
> points.
> > > > > > >
> > > > > > >
> > > > > > > > `build`
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > What happens when a user specifies both --debug and --release?
> > > > > > >
> > > > > > >
> > > > > > > I'm happy as long as we decide on what happens. For the sake of
> > > ease, I
> > > > > > > think it would be better to just fail.
> > > > > > >
> > > > > > > This brings up the question of exit codes. I don't want to over
> > > > engineer,
> > > > > > > but should we distinguish between an exit code for an
> "unsupported
> > > > > > > command"
> > > > > > > and "runtime command error" (e.g. unsupported argument
> combination)?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > As
> > > > > > > long as there is a message with the exit code, it's not
> necessary but
> > > > > > > could
> > > > > > > provide a good hint to higher-level tools.
> > > > > > >
> > > > > > > `run [--target=<id>]`
> > > > > > >
> > > > > > >
> > > > > > > I like the term `run` and how it will implicitly invokes
> `build` when
> > > > > > > necessary. This will be the go-to command for most developers.
> > > > > > >
> > > > > > > `list-emulator-images`
> > > > > > > > ...
> > > > > > > > `list-started-emulators`
> > > > > > > > ...
> > > > > > > > `list-devices`
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The listing format is: "ID: DESCRIPTION". What will it look
> like when
> > > > no
> > > > > > > description is provided? "ID" or "ID:"?
> > > > > > >
> > > > > > > Is it possible to remove the colon entirely and delimit on a
> space?
> > > "ID
> > > > > > > DESCRIPTION" and "ID"
> > > > > > >
> > > > > > > `deploy-emulator`
> > > > > > > > ...
> > > > > > > > `deploy-device`
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Deploy is a confusing term because it's too similar to "run."
> Even
> > > both
> > > > > > > command definitions use the term "deploy."
> > > > > > >
> > > > > > > I'd like to propose renaming the deploy commands to:
> > > `install-emulator`
> > > > > > > and
> > > > > > > `install-device`.
> > > > > > >
> > > > > > > Install more clearly describes the action and implies that it
> does
> > > not
> > > > > > > implicitly build first.
> > > > > > >
> > > > > > > Again, awesome work Fil!
> > > > > > > Michael
> > > > > > >
> > > > > > > On Tue, Mar 26, 2013 at 4:16 PM, Filip Maj <f...@adobe.com(mailto:
> f...@adobe.com)> wrote:
> > > > > > >
> > > > > > > > Thanks Shaz, updated the wiki article.
> > > > > > > >
> > > > > > > > On 3/26/13 4:07 PM, "Shazron" <shaz...@gmail.com (mailto:
> shaz...@gmail.com)> wrote:
> > > > > > > >
> > > > > > > > > * log is only the Simulator
> > > > > > > > > * build release/debug -- last one clobbers? depending on
> how the
> > > > > > > > >
> > > > > > > >
> > > > > > > > parsing
> > > > > > > > > is
> > > > > > > > > implemented
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj 
> > > > > > > > > <f...@adobe.com(mailto:
> f...@adobe.com)> wrote:
> > > > > > > > >
> > > > > > > > > > OK, I've done some rehash of the proposal and put it up
> on the
> > > > wiki:
> > > > > > > > > > http://wiki.apache.org/cordova/CommandLineToolingDesign
> > > > > > > > > >
> > > > > > > > > > Please take a look and post back if you have questions,
> > > > > disagreement,
> > > > > > > > > > want
> > > > > > > > > > to +1 it, etc.
> > > > > > > > > >
> > > > > > > > > > At the top there is a generic multi-device flow that can
> solve a
> > > > lot
> > > > > > > > of
> > > > > > > > > > the consistency issues we've seen before.
> > > > > > > > > >
> > > > > > > > > > Assuming this proposal is on track, there are three
> outstanding
> > > > > > > > > > questions.
> > > > > > > > > >
> > > > > > > > > > Two for the `log` command:
> > > > > > > > > >
> > > > > > > > > > * Does the current iOS implementation only work for
> simulator,
> > > or
> > > > > > > > > > device,
> > > > > > > > > > or either, or neither?
> > > > > > > > > > * Does the multi-device flow apply correctly to the log
> case? It
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > seems
> > > > > > > > > > identifying whether the user's Cordova application is
> running on
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > an
> > > > > > > > > > emulator or device target would need to be figured out.
> > > > > > > > > >
> > > > > > > > > > One about the build command:
> > > > > > > > > >
> > > > > > > > > > * What happens when a user specifies both --release and
> --debug,
> > > > > I.e.
> > > > > > > > > > `build --release --debug`?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 3/25/13 1:54 PM, "Michael Brooks" <
> mich...@michaelbrooks.ca (mailto:mich...@michaelbrooks.ca)>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > To be absolutely clear, the above is NOT the
> motivation for
> > > > > > > > changing
> > > > > > > > > > > > this
> > > > > > > > > > > > stuff around. Cordova-cli needs consistency across
> platforms.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is
> > > > > > > > > > > > the
> > > > > > > > > > > > motivation.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Yep, as long as we can guarantee that each script
> follows a
> > > > > > > > predictable
> > > > > > > > > > > input and output, I don't care how we implement it.
> > > > > > > > > > >
> > > > > > > > > > > If you guys really want a single entry-point with
> flags, then
> > > go
> > > > > > > > nuts,
> > > > > > > > > > but
> > > > > > > > > > > we will need to clearly define what happens when:
> > > > > > > > > > >
> > > > > > > > > > > - no flag is provided e.g. `build`
> > > > > > > > > > > - multiple flags are provided e.g. `build --release
> --debug`
> > > > > > > > > > >
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > +1 to adding a script that validates a platform's SDK
> > > > requirements.
> > > > > > > > > > >
> > > > > > > > > > > This script should not need to modify project files to
> assert
> > > the
> > > > > > > > SDK
> > > > > > > > > > > requirements. I mention this because the current
> `cordova-cli`
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Android
> > > > > > > > > > > `check_requirements` must successfully update the
> Android
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > project
> > > > > > > > > > target
> > > > > > > > > > > before returning true. However, consider the scenario
> where you
> > > > > > > > > >
> > > > > > > > > > validate
> > > > > > > > > > > the SDK before adding the platform - in this case, the
> Android
> > > > > > > > > > > `check_requirements` will always fail.
> > > > > > > > > > >
> > > > > > > > > > > Michael
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj <
> f...@adobe.com (mailto:f...@adobe.com)>
> > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Hopefully, next time we will change/update these
> things it
> > > > will
> > > > > > > > be
> > > > > > > > > > for
> > > > > > > > > > > > a
> > > > > > > > > > > > > real reason (such as SDK tools updates etc...) and
> not
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > > because
> > > > > we
> > > > > > > > > > think
> > > > > > > > > > > > > that there might be a better implementation in C#.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > To be absolutely clear, the above is NOT the
> motivation for
> > > > > > > > changing
> > > > > > > > > > > > this
> > > > > > > > > > > > stuff around. Cordova-cli needs consistency across
> platforms.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is
> > > > > > > > > > > > the
> > > > > > > > > > > > motivation.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>

Reply via email to