You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2012/03/29 21:55:47 UTC
command line tooling, and plugin design wiki pages
I've created some stubs here, based on conversation in the "git 2.x
separate branch thread".
- http://wiki.apache.org/cordova/CommandLineToolingDesign
- http://wiki.apache.org/cordova/PluginDesign
Or do we already have something, somewhere, to use instead?
Hopefully I'll get a chance to do a brain dump into these today/tomorrow.
But feel free to dump your own brains there!
--
Patrick Mueller
http://muellerware.org
Re: command line tooling, and plugin design wiki pages
Posted by Brian LeRoux <b...@brian.io>.
also check the old wiki and andrew lunny has a tool called
plugin-install for ios/android
On Thu, Mar 29, 2012 at 1:14 PM, Brian LeRoux <b...@brian.io> wrote:
> yah. there is tonnes of prior art for this stuff. I will update the
> wiki but quickly
>
> https://github.com/brianleroux/Cordova/tree/b816aacfb7583174be9f44f71dc32c8465d13109
> was stable
>
> then other things happened. those scripts ended up in the mainline
> projects. the idea was a standard package format for a project and
> upgrading would consist only of swapping out the bin directory. the
> scripts would live local the project avoiding version hell between
> releases.
>
> this new thinking is different. we now think the native project as it
> were should host its own scripts. upgrading not a consideration. maybe
> it should be. you're thinking of a master global script, which is cool
> and something I've always wanted, but the version thing needs to be
> considered. perhaps not an issue between releases if the native
> project (the target of www) deals with the version itself...
>
> anyhow, lots to chew on there. phone call or, better, F2F might help
>
>
>
> On Thu, Mar 29, 2012 at 12:55 PM, Patrick Mueller <pm...@gmail.com> wrote:
>> I've created some stubs here, based on conversation in the "git 2.x
>> separate branch thread".
>>
>> - http://wiki.apache.org/cordova/CommandLineToolingDesign
>> - http://wiki.apache.org/cordova/PluginDesign
>>
>> Or do we already have something, somewhere, to use instead?
>>
>> Hopefully I'll get a chance to do a brain dump into these today/tomorrow.
>> But feel free to dump your own brains there!
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
Re: command line tooling, and plugin design wiki pages
Posted by Michael Brooks <mi...@gmail.com>.
I also updated the wiki articles with a few documentation notes. We want to start encouraging good documentation of each plugin.
Michael
On 2012-04-06, at 10:15 PM, Filip Maj <fi...@adobe.com> wrote:
> I've updated the PluginDesign [1] wiki article's sections on JavaScript
> and native file structure with my suggestions. These are all based on the
> existing native plugin interfaces and the one we are slowly building up
> via cordova-js.
>
> [1] http://wiki.apache.org/cordova/PluginDesign
>
> On 3/29/12 1:49 PM, "Patrick Mueller" <pm...@gmail.com> wrote:
>
>> On Thu, Mar 29, 2012 at 16:40, Brian LeRoux <b...@brian.io> wrote:
>>
>>> hackathon even better; agree on design consensus and code. all I ask
>>> is: pls no camel case in my cli!!! (unless we want to scope bash
>>> completion with this... lol)
>>>
>>
>> Sadly, bash completion scripting is a dark art I've managed to avoid
>> up-till-now.
>>
>> But, seriously, it should probably be listed as a want-to-have.
>>
>> 1) it would be useful
>> 2) it will force us to be consistent, in terms of the command-line API
>> arguments, and what not.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>
Re: command line tooling, and plugin design wiki pages
Posted by Filip Maj <fi...@adobe.com>.
I've updated the PluginDesign [1] wiki article's sections on JavaScript
and native file structure with my suggestions. These are all based on the
existing native plugin interfaces and the one we are slowly building up
via cordova-js.
[1] http://wiki.apache.org/cordova/PluginDesign
On 3/29/12 1:49 PM, "Patrick Mueller" <pm...@gmail.com> wrote:
>On Thu, Mar 29, 2012 at 16:40, Brian LeRoux <b...@brian.io> wrote:
>
>> hackathon even better; agree on design consensus and code. all I ask
>> is: pls no camel case in my cli!!! (unless we want to scope bash
>> completion with this... lol)
>>
>
>Sadly, bash completion scripting is a dark art I've managed to avoid
>up-till-now.
>
>But, seriously, it should probably be listed as a want-to-have.
>
>1) it would be useful
>2) it will force us to be consistent, in terms of the command-line API
>arguments, and what not.
>
>--
>Patrick Mueller
>http://muellerware.org
Re: command line tooling, and plugin design wiki pages
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Mar 29, 2012 at 16:40, Brian LeRoux <b...@brian.io> wrote:
> hackathon even better; agree on design consensus and code. all I ask
> is: pls no camel case in my cli!!! (unless we want to scope bash
> completion with this... lol)
>
Sadly, bash completion scripting is a dark art I've managed to avoid
up-till-now.
But, seriously, it should probably be listed as a want-to-have.
1) it would be useful
2) it will force us to be consistent, in terms of the command-line API
arguments, and what not.
--
Patrick Mueller
http://muellerware.org
Re: command line tooling, and plugin design wiki pages
Posted by Brian LeRoux <b...@brian.io>.
> Great, thx. I'll integrate some of this info on the wiki, when I get a
> chance, if you haven't already.
cool, ya today prolly not
>> anyhow, lots to chew on there. phone call or, better, F2F might help
>>
>
> Hackathon? But it would be nice to get consensus on some overall design
> aspects, before F2F. I'd rather spend time hacking code, instead of
> white-boarding, as much as possible.
hackathon even better; agree on design consensus and code. all I ask
is: pls no camel case in my cli!!! (unless we want to scope bash
completion with this... lol)
Re: command line tooling, and plugin design wiki pages
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Mar 29, 2012 at 16:14, Brian LeRoux <b...@brian.io> wrote:
> yah. there is tonnes of prior art for this stuff. I will update the
> wiki but quickly ...
>
Great, thx. I'll integrate some of this info on the wiki, when I get a
chance, if you haven't already.
> anyhow, lots to chew on there. phone call or, better, F2F might help
>
Hackathon? But it would be nice to get consensus on some overall design
aspects, before F2F. I'd rather spend time hacking code, instead of
white-boarding, as much as possible.
--
Patrick Mueller
http://muellerware.org
Re: command line tooling, and plugin design wiki pages
Posted by Brian LeRoux <b...@brian.io>.
yah. there is tonnes of prior art for this stuff. I will update the
wiki but quickly
https://github.com/brianleroux/Cordova/tree/b816aacfb7583174be9f44f71dc32c8465d13109
was stable
then other things happened. those scripts ended up in the mainline
projects. the idea was a standard package format for a project and
upgrading would consist only of swapping out the bin directory. the
scripts would live local the project avoiding version hell between
releases.
this new thinking is different. we now think the native project as it
were should host its own scripts. upgrading not a consideration. maybe
it should be. you're thinking of a master global script, which is cool
and something I've always wanted, but the version thing needs to be
considered. perhaps not an issue between releases if the native
project (the target of www) deals with the version itself...
anyhow, lots to chew on there. phone call or, better, F2F might help
On Thu, Mar 29, 2012 at 12:55 PM, Patrick Mueller <pm...@gmail.com> wrote:
> I've created some stubs here, based on conversation in the "git 2.x
> separate branch thread".
>
> - http://wiki.apache.org/cordova/CommandLineToolingDesign
> - http://wiki.apache.org/cordova/PluginDesign
>
> Or do we already have something, somewhere, to use instead?
>
> Hopefully I'll get a chance to do a brain dump into these today/tomorrow.
> But feel free to dump your own brains there!
>
> --
> Patrick Mueller
> http://muellerware.org