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. >>> >> >> >>> >> >> >>> >> >>> >> >>> >
