incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin tooling/specification
Date Tue, 11 Sep 2012 15:05:40 GMT
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
<reinstein.mike@gmail.com>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 <mmocny@chromium.org>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
>> <reinstein.mike@gmail.com>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 <mmocny@chromium.org>
>> > 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 <b@brian.io> wrote:
>> > >
>> > > > Considering the source I'd say 'baked' was intentional.
>> > > >
>> > > >
>> > > > On Tue, Sep 11, 2012 at 5:29 AM, Mike Reinstein
>> > > > <reinstein.mike@gmail.com> 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 <b@brian.io>
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!)
>> > > > >>
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message