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