+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> 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> wrote:
> > FYI issues for all of these scripts have been filed.
> >
> > On 3/28/13 1:31 PM, "Michael Brooks" <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> wrote:
> >>
> >>> Thanks Shaz, updated the wiki article.
> >>>
> >>> On 3/26/13 4:07 PM, "Shazron" <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> 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>
> >>>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> 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