Return-Path: 
 <dev-return-31795-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
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 821F411E54
	for <apmail-cordova-dev-archive@www.apache.org>;
 Wed,  9 Apr 2014 21:25:48 +0000 (UTC)
Received: (qmail 49375 invoked by uid 500); 9 Apr 2014 21:25:47 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 49346 invoked by uid 500); 9 Apr 2014 21:25:47 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 49338 invoked by uid 99); 9 Apr 2014 21:25:47 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2014 21:25:47 +0000
X-ASF-Spam-Status: No, hits=2.5 required=5.0
	tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gorkem.ercan@gmail.com
 designates 209.85.213.42 as permitted sender)
Received: from [209.85.213.42] (HELO mail-yh0-f42.google.com) (209.85.213.42)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Apr 2014 21:25:42 +0000
Received: by mail-yh0-f42.google.com with SMTP id t59so3027855yho.29
        for <dev@cordova.apache.org>; Wed, 09 Apr 2014 14:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=d0Hgb9tZk3LJzUVQv5ermwShRRwUkLYDOWhZA37mQWY=;
        b=fGcuaGRhDaDQ5ivN7rQhHeoK3hmWzwVUpCP2DBzxVtYEUObYlvEi3aA/TnxWBg8KVW
         LnVGtY6Cx/Fks5xRXqJCpcvZJCbX4Ecx9fwGlAQa4ulG2ZXBihX+AP+0zgGwlRepeX9B
         d9bSyG0Nmkc4B0tUfowrhRxhLdWXLV5gCRW07Ego7V6EgADtwS5S6Nhvqi5XyXofX0w+
         /4Qq8eVxWJeq+di4lVhZJVmkns9oH1qroriOLmjibG/gJbuJBXtabDxqqhD+W4zQSvY/
         alndlNTO0ISD/1+b8Rq2mczg7Vc3M6UKfm94tJhelUKXxNCUsc79hQ+mRofM3iqhYNaq
         sf4w==
MIME-Version: 1.0
X-Received: by 10.236.74.229 with SMTP id x65mr3471144yhd.131.1397078722179;
 Wed, 09 Apr 2014 14:25:22 -0700 (PDT)
Received: by 10.170.135.193 with HTTP; Wed, 9 Apr 2014 14:25:22 -0700 (PDT)
In-Reply-To: 
 <CAEeF2Td2XUFGy9m=MSCsOdC6+xvFE4b3+SYndU7wAFjCf=DTeQ@mail.gmail.com>
References: 
 <CA+X37cmqxjgedWOnOQEVLspnEYvXVFsCwaZSbPk7UjYRG4FDWQ@mail.gmail.com>
	<CAD_dpu3P0UrXPLMzSvR8qVechEnaX6uk164hoFHaZHM+97KHTA@mail.gmail.com>
	<CA+X37ckdTMLPVC=nySOg4KNYjYsabeGVeBtf_v1e2d1NznCcqw@mail.gmail.com>
	<CABiQX1U2BwRVvRpN+mLGRNWJesR5BjbfKGcC=NXZt=V6WiEVdA@mail.gmail.com>
	<CAEeF2Td2XUFGy9m=MSCsOdC6+xvFE4b3+SYndU7wAFjCf=DTeQ@mail.gmail.com>
Date: Wed, 9 Apr 2014 15:25:22 -0600
Message-ID: 
 <CA+X37ckfnTu0CnTV15uzaa7beQ4Q_veP_7Wxc0CCWKp35nkrzg@mail.gmail.com>
Subject: Re: engines and plugins on config.xml
From: Gorkem Ercan <gorkem.ercan@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=20cf3005144cf5792c04f6a2bc84
X-Virus-Checked: Checked by ClamAV on apache.org

--20cf3005144cf5792c04f6a2bc84
Content-Type: text/plain; charset=ISO-8859-1

Agreed, I was thinking about making the version attribute optional which
would basically signal CLI to create platforms with the latest&greatest
platforms releases.
--
Gorkem


On Wed, Apr 9, 2014 at 12:45 PM, Michal Mocny <mmocny@chromium.org> wrote:

> This would be a great contribution.
>
> We should consider using the <dependency> tag for plugins, which I think
> maps well to existing specifications for urls and versions.
>
> For platforms, I'm fine with <engine>, though I don't like tieing to
> specific versions by default.  I think we should support it, but my usual
> reason for project re-creation is a trivial way to upgrade everything.
>
> Thanks for signing up!
>
> -Michal
>
>
> On Wed, Apr 9, 2014 at 12:45 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Gorkem - if you implement this you'll be my hero!
> >
> > <engine> vs <platform> is a bit weird, because <platform> is already a
> > thing that exists right now that is meant to mean tags within it apply
> only
> > to the platform is lists. E..g
> > <platform name="android">
> >   <preference name="foo" value="3" />
> > </platform>
> >
> >
> > On one hand, you could throw a version in there, but given that you can
> > have multiple <platform> tags, it's a bit weird. I can also see the
> > use-case of wanting: <platform name="android|ios">.
> >
> > So... wanted to point this out for consideration, but think that <engine>
> > might be better because if this reason.
> >
> >
> > I think the argument is more compelling to have plugins use <cdv:plugin>
> > rather than <feature>. I think we'd only want:
> > <cdv:plugin name="" version="" />
> > And not have end-users need to add in the <param name="package-name"/>,
> > since that's up to the plugin.xml to add in.
> >
> >
> >
> >
> > On Wed, Apr 9, 2014 at 8:09 AM, Gorkem Ercan <gorkem.ercan@gmail.com>
> > wrote:
> >
> > > I guess it could be platform as well. I put engine because that is what
> > > plugin.xml uses for its dependencies.
> > > --
> > > Gorkem
> > >
> > >
> > > On Wed, Apr 9, 2014 at 10:01 AM, Sebastien Blanc <scm.blanc@gmail.com
> > > >wrote:
> > >
> > > > I had the same idea and I really love it
> > > > but why not "platform" instead of "engine" ?
> > > >
> > > >
> > > >
> > > > On Wed, Apr 9, 2014 at 5:58 PM, Gorkem Ercan <gorkem.ercan@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > I would like to propose a couple of enhancements to the top level
> > > > > config.xml that would enable us to recreate a project easily.
> > > > >
> > > > > (Note: the examples below assumes a cdv namespace on config.xml)
> > > > >
> > > > > 1. engines tag :
> > > > >
> > > > > <cdv:engine id="org.apache.cordova.android" version="3.5.1" />
> > > > > <cdv:engine id="org.apache.cordova.ios" version="3.7.0" />
> > > > >
> > > > > CLI could use this tag the reconstruct the platforms hence the
> > > platforms
> > > > > folder would really become a build artifact. I believe phonegap and
> > the
> > > > > JBoss IDE is already using a similiar thing on the
> > .cordova/config.json
> > > > >
> > > > > 2. plugins
> > > > >
> > > > > <feature name="Console" cdv:id="org.apache.cordova.core.console"
> > > > > cdv:version="0.2.8">
> > > > >            <param name="ios-package" value="ConsolePlugin" />
> > > > > </feature>
> > > > >
> > > > > Alternately
> > > > >
> > > > > <feature name="Console">
> > > > >      <param name="id" value="org.apache.cordova.core.console" />
> > > > >     <param name="version" value="0.2.8" />
> > > > >      <param name="ios-package" value="ConsolePlugin" />
> > > > > </feature>
> > > > >
> > > > > This is reutilizing the existing feature tag. ID is the only
> missing
> > > > piece
> > > > > of information for CLI to reinstall the plugins to a project is the
> > > > plugin
> > > > > id and version. This would also eliminate the need to share plugins
> > > > folder
> > > > > with the Cordova projects. The plugins folder can still be utilized
> > for
> > > > > plugins that were not available from plugin registry. Also if the
> id
> > is
> > > > > missing on a feature tag CLI would skip restoring that plugin for
> the
> > > > > project.
> > > > >
> > > > > On top of this I am volunteering myself to do the work. I guess it
> > will
> > > > > require a good amount of changes to CLI prepare.
> > > > >
> > > > > ---
> > > > > Gorkem
> > > > >
> > > >
> > >
> >
>

--20cf3005144cf5792c04f6a2bc84--