cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <>
Subject Re: Pluginstall tool discussion
Date Wed, 10 Oct 2012 00:00:44 GMT
Hi Andrew,

I agree on all points. Some additional feedback on a few specifics:

> It looks like Mike has made a start on that with his
> cordova-pluginrepo repository

Correct! Thanks for taking the time to look at it. I'm hoping to have a
working prototype by end of week.

> The only way to find those problems is to try writing those plugins.

Agreed, though I think inspecting existing plugins is a good start too.
Have you had a chance to look at my google docs spreadsheet on plugin work?
tab 1 is a grid of all plugins and their supported platforms, plus a few
bits of meta data. Tab 3 was my attempt to go through some of the more
"popular" plugins, analyizing their suitability for packaging via
pluginstall. Where it fell short I documented. Green means good to go
as-is, red means some issues, yellow means unsure (might be ok.) I'd love
some more feedback on this. the doc is globally shared so everyone can
modify it. I think we could use tab 3 to coordinate our work and provide
visibility. thoughts?


On Tue, Oct 9, 2012 at 7:44 PM, Andrew Lunny <> wrote:

> I've missed most of this discussion, but I wanted to make a few quick
> points:
> * `pluginstall` (the tool I developed, that is used by PhoneGap Build) is a
> tool for installing plugins. Per the Unix philosophy, it doesn't and won't
> do anything other than that.
> * There may well be a need and a demand for a tool that grabs plugins from
> git repositories, uninstalls plugins, generates starter plugins, etc. But
> that's not pluginstall, and I think that tool should probably be named
> something else. It looks like Mike has made a start on that with his
> cordova-pluginrepo repository, which is awesome.
> * The problems that need to be solved by pluginstall are of the form "I
> can't install plugin x with pluginstall", or "I can't write a plugin that
> does x that can be installed by pluginstall." The only way to find those
> problems is to try writing those plugins. The PGB team is moving forward on
> a few, and we've worked with some other companies who have helped us see
> where pluginstall was lacking (adding multiple children to an Android
> intent-filter, installing a dylib into an iOS project).
> * node-xcode is a separate project, and will be useful for any plugin tools
> written with node. It would probably be better for everyone's sanity if
> there was a single version of that parser. I've been pretty slack about
> merging changes, so I'll get up to speed on that.
> * If other tools want to interoperate with pluginstall, they should follow
> the plugin spec here:
> That's a working document and is open to changes. Again, my preference is
> for changes of the form "I can't write a plugin that does X in this format"
> rather than "this element has a slightly misleading name; how about this
> name?". The GitHub issues for that repo is the best place to discuss
> changes to that spec.
> Cheers,
> Andrew
> On 6 October 2012 09:08, Mike Reinstein <> wrote:
> > Andrew's is the one used by pg build. Anis has changes from all of us and
> > has the most the up to date code:
> >
> >
> >
> > -Mike
> >
> >
> >
> > On Sat, Oct 6, 2012 at 8:08 AM, Patrick Mueller <>
> wrote:
> >
> > > On Sat, Oct 6, 2012 at 5:22 AM, Brian LeRoux <> wrote:
> > >
> > > > Think its time we nominated a canonical repo for this. Fil's?
> > > >
> > >
> > > URL please?  Are we talking about forks of pluginstall?
> > >
> > > --
> > > Patrick Mueller
> > >
> > >
> >

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