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