I'd like to propose we replace the contents of this wiki page http://wiki.apache.org/cordova/CommandLineToolingDesign with a simple note that points at the correct url "This documentation has merged into https://github.com/apache/incubator-cordova-labs/tree/cordova-client";
Are there any other copies of this doc in other places? Other forks we can eliminate to reduce confusion? Has anyone heard from Andrew Lunny recently? I still have my change docs that I submitted as a pull request but havent gotten any feedback, and it seems like he hasn't been active on github in a few weeks. I'd prefer to get the changes for pluginstall merged in so I can remove my copy. -Mike On Tue, Sep 11, 2012 at 10:52 AM, Mike Reinstein <[email protected]>wrote: > > Subcommand argument formats still look off a bit > Fixed > > > I think the $ is unneeded. All the other shell code > > examples don't include the leading shell character. > > Actually, the opposite. Every example did have leading $ except for the > first usage, which was inconsistent. But I agree $ is essentially just > noise and have removed all instances from the doc. :) > > It would be nice to clean up the Random notes section. I think there may > be some context associated with those chat discussion snippets that were > copy/pasted in, so expanding on those points would be helpful for everyone > else (including me.) > > > > On Tue, Sep 11, 2012 at 10:41 AM, Michal Mocny <[email protected]>wrote: > >> Subcommand argument formats still look off a bit, I think they should look >> as follows: >> >> create <directory> [<id> [<name>]] >> platform ls >> platform add <platform> >> platform remove <platform> >> plugin ls >> plugin add <path-to-plugin> (NOTE: why use "path-to-" here? Seems >> inconsistant with the other examples of add/remove) >> plugin remove <plugin> >> build >> emulate >> >> >> >> Also, in the line "you can access the tool via $ cordova" I think the $ >> is >> unneeded. All the other shell code examples don't include the leading >> shell character. Alternatively we can add shell character to all the >> other >> shell command examples. >> >> >> On Tue, Sep 11, 2012 at 10:24 AM, Mike Reinstein >> <[email protected]>wrote: >> >> > I've updated my copy of the README.md, pulling changes from Filip, >> Michal, >> > and Brian: >> > >> https://github.com/mreinstein/incubator-cordova-labs/tree/cordova-client >> > >> > If I've missed anything please let me know. >> > >> > -Mike >> > >> > On Tue, Sep 11, 2012 at 10:22 AM, Michal Mocny <[email protected]> >> > wrote: >> > >> > > I'm still unsure what a "baked in" plugin/platform would be, in that >> > > context. Anyway, its not super important as the actual argument types >> > may >> > > change over time. The gist of it is just that you can reference a >> > > plugin/platform using various typical methods and I think that point >> gets >> > > across well enough. >> > > >> > > >> > > On Tue, Sep 11, 2012 at 8:38 AM, Brian LeRoux <[email protected]> wrote: >> > > >> > > > Considering the source I'd say 'baked' was intentional. >> > > > >> > > > >> > > > On Tue, Sep 11, 2012 at 5:29 AM, Mike Reinstein >> > > > <[email protected]> wrote: >> > > > >> assumed to be a 'backed in' platform/plugin >> > > > > >> > > > > This must be a typo, eh? 'baked' was intended? >> > > > > >> > > > > On Tue, Sep 11, 2012 at 4:15 AM, Brian LeRoux <[email protected]> wrote: >> > > > > >> > > > >> > * You will be able to access the client interface via: $ >> > > ./bin/cordova >> > > > >> > * * suggest replacing ./ with $(CORDOVA_CLIENT_DIR)/ >> > > > >> >> > > > >> Agree...tho the npm install should be global (in /usr/local/bin) >> > > > >> ....maybe we say as much? >> > > > >> >> > > > >> >> > > > >> > * Subcommands section >> > > > >> > * * Typical unix manpage style is to use [] to surround >> optional >> > > > >> arguments >> > > > >> > <> to surround explanations and nothing for keywords. Examples >> > that >> > > > need >> > > > >> > fixing include: >> > > > >> > * * * create <directory> [<id>] [<name>] >> > > > >> > * * * platform ls >> > > > >> > * * * platform add <platform> >> > > > >> > * * * etc >> > > > >> > * * even if we aren't aiming for manpage style here, there >> > > > >> > are inconsistencies >> > > > >> >> > > > >> Sure >> > > > >> >> > > > >> >> > > > >> > * * File and Directory Structure ascii tree diagram >> > > > >> > * * * suggest appending / after directory names >> > > > >> >> > > > >> +1 >> > > > >> >> > > > >> >> > > > >> > * * ... it's assumed to be a 'backed in' platform/plugin. >> > Otherwise, >> > > > it's >> > > > >> > assumed to be a URL to a gzipped tar archive... >> > > > >> > * * * Not sure what 'backed in' means here, nor how to identify >> > > > something >> > > > >> > as not being backed in so as to fallback to gzipped tar >> > > > >> > * * * Also wording sounds more like "else .. else" instead of >> > "else >> > > > if .. >> > > > >> > else" (if that makes sense) :P >> > > > >> >> > > > >> Ya not sure what this is about? >> > > > >> >> > > > >> >> > > > >> > * * KewlApp directory structure ascii tree diagram >> > > > >> > * * * based on my understanding of the text, the ios/android >> > > platforms >> > > > >> > should be subdirs of platforms/ and there should also be a >> subdir >> > > > listed >> > > > >> in >> > > > >> > plugins/ >> > > > >> >> > > > >> Yes. >> > > > >> >> > > > >> >> > > > >> > * * Running tests warning >> > > > >> > * * * Perhaps explain how to bootstrap so as not to have >> failing >> > > tests >> > > > >> > instead of assuming the reverse? >> > > > >> >> > > > >> Yes. >> > > > >> >> > > > >> >> > > > >> > Also, I will look into bash completions in some spare cycles >> and >> > if >> > > it >> > > > >> > looks reasonable I may volunteer for the task. I've been >> curious >> > to >> > > > >> learn >> > > > >> > how those work :) >> > > > >> >> > > > >> That'd be awesome...but I'm thinking in a future iteration once >> the >> > > > >> actual CLI API is more solid. (But knock yourself out!) >> > > > >> >> > > > >> > > >> > >> > >
