Yes, templates are definitely in the roadmap. A lot of people have
requested it. The goal is to make it super easy for plugin authors to make
their plugins install-able/discoverable.

I didn't ask for a second manifest. Right now plugin authors can register
plugins to the cordova universe via a web form
(http://plugins.cordova.iowhich I haven't advertised much). We can
just ask them to specify their
plugin version and compatible corodova version and we will deal with the
rest. Eventually, they should be able to publish/unpublish newer versions
directly through plugman (kinda like npm publish).

So big NO to other manifests, it's already hard enough to convince people
to convert their existing plugins to make them compatible with our spec.


On Fri, Mar 22, 2013 at 7:52 PM, Tommy-Carlos Williams
<[email protected]>wrote:

> Yeah exactly… I think it would a great bridge over the moat that has been
> built up around plugin authoring over the last year or so…
>
> - tommy
>
> On 23/03/2013, at 1:46 PM, Michal Mocny <[email protected]> wrote:
>
> > Huge +1 to plugin templates.
> >
> > (we already have an app template, right?)
> >
> > -Michal
> >
> >
> > On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams
> > <[email protected]>wrote:
> >
> >> The barrier of having more config files is real and change is starting
> to
> >> cause fatigue amongst the plugin authors I deal with regularly.
> >>
> >> Having said that, I think JSON would be a welcome change overall…
> >>
> >> There really are not that many plugins that are set up with a plugin.xml
> >> yet that I know of anyway. People on this list are probably the authors
> or
> >> maintainers of most of them. ;)
> >>
> >> I know we are going to start getting tool fatigue ourselves soon, but
> >> would something like npm's init[1] be useful to alleviate some of the
> >> barriers? Much like the cordova cli sets you up with a folder structure
> >> (similarly the yeoman tooling for web dev) maybe we could add a command
> to
> >> ask a few questions (or take a few args) and spit out some sane defaults
> >> and create a structure for plugin dev?
> >>
> >> - Tommy-Carlos "fighting for plugin authors since 2010" Williams
> >>
> >> :P
> >>
> >>
> >> [1] https://npmjs.org/doc/init.html
> >>
> >>
> >>
> >> On 23/03/2013, at 1:18 PM, Michal Mocny <[email protected]> wrote:
> >>
> >>> I generally prefer json whenever possible as well, so if its feasible
> to
> >>> change I'de give that a +1, but I'm not sure how many plugins out there
> >>> already use the manifest based structure.
> >>>
> >>> As far as creating a second manifest just to register with a universe,
> >> this
> >>> isn't unheard of may have benefits, but its yet another barrier for
> entry
> >>> for 3rdparty plugin devs.  It would be really awesome if sharing
> plugins
> >>> with the world were as simple as providing a git repo+tag+directory.
>  I'm
> >>> not sure I buy the versioning argument, whatever structure we come up
> >> with
> >>> for version dependancies will have the same likelihood of changing over
> >>> time no matter which file we put it in.
> >>>
> >>> -Michal
> >>>
> >>>
> >>> On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI <[email protected]>
> >> wrote:
> >>>
> >>>> Yeah the only issue with plugin.xml is that it's ....XML :-D
> >>>>
> >>>> It would be so much easier to have it stored in JSON. We can make
> >> plugman
> >>>> parse the XML from a remote source but I would rather store everything
> >> in
> >>>> JSON.
> >>>>
> >>>> Also there can be multiple versions of plugin.xml. I think that is a
> >> good
> >>>> enough reason to store the relevant data about plugins (compatible
> >> cordova
> >>>> versions with a given plugin version, dependencies, etc...) in an
> >>>> easy-to-read format (JSON). There is a bit of duplication yes but it's
> >> for
> >>>> a good cause and the gain is huge.
> >>>>
> >>>> The submission process would be:
> >>>> - A plugin author submits a new plugin, gives it a version and
> specifies
> >>>> which version of cordova it was tested on.
> >>>> - A new version of Cordova comes out and requires the plugin author to
> >>>> update their plugin to stay compatible.
> >>>> - We start building the Cordova version <=> plugin version mapping
> like
> >>>> that.
> >>>>
> >>>> Thoughts ?
> >>>>
> >>>> -a
> >>>>
> >>>>
> >>>> On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux <[email protected]> wrote:
> >>>>
> >>>>> makes sense to me; we'll likely want to query on that stuff
> eventually
> >>>>>
> >>>>> On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny <[email protected]>
> >>>>> wrote:
> >>>>>> Should the universe just keep a copy of a plugin.xml so that it can
> >>>> have
> >>>>> a
> >>>>>> list of plugin dependancies and everything?  plugin.xml will already
> >>>>> have a
> >>>>>> list of compatible cordova versions, right?
> >>>>>>
> >>>>>> Then the universe can manage a reverse mapping if it wants fast
> >> access.
> >>>>>>
> >>>>>> -Michal
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux <[email protected]> wrote:
> >>>>>>
> >>>>>>> A plugin should specify the Cordova versions it supports too.
> >>>>>>>
> >>>>>>> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux <[email protected]> wrote:
> >>>>>>>> I am sure we all agree to this. Want to get a sense of how it will
> >>>>>>>> happen. Anis you mentioned you need Braden to commit the JS stuff
> >>>>>>>> first?
> >>>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

Reply via email to