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? >>>>> >>> >>
