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