Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2D1E7FE5D for ; Sun, 24 Mar 2013 20:16:27 +0000 (UTC) Received: (qmail 86658 invoked by uid 500); 24 Mar 2013 20:16:27 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 86619 invoked by uid 500); 24 Mar 2013 20:16:26 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 86607 invoked by uid 99); 24 Mar 2013 20:16:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Mar 2013 20:16:26 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [216.13.78.11] (HELO smtp-server.com) (216.13.78.11) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Mar 2013 20:16:21 +0000 X-mail-policy: SMTP-SERVER.COM is a commercial mail relay service. We do not tolerate unsolicited commercial email and we will deal strictly with any of our subscribers who participate in such practice. Report: abuse@smtp-server.com Received: from [192.168.1.103] (126.Red-2-140-50.dynamicIP.rima-tde.net [2.140.50.126]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp-server.com (Postfix) with ESMTP id B0A4917B904 for ; Sun, 24 Mar 2013 20:15:57 +0000 (UTC) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Sun, 24 Mar 2013 21:19:39 +0100 Subject: Re: [plugman] universe and plugin version support needed From: Giorgio Natili To: Message-ID: Thread-Topic: [plugman] universe and plugin version support needed In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org +1 to plugin templates On 3/23/13 3:46 AM, "Michal Mocny" 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 >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=8A >> >> 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 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 >> 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 <=3D> plugin version mapping >>like >> >> that. >> >> >> >> Thoughts ? >> >> >> >> -a >> >> >> >> >> >> On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux 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 >> >>> 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 wrote: >> >>>> >> >>>>> A plugin should specify the Cordova versions it supports too. >> >>>>> >> >>>>> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux 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? >> >>>>> >> >>> >> >> >> >>