Return-Path: 
 <dev-return-36909-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 952BD1195C
	for <apmail-cordova-dev-archive@www.apache.org>;
 Wed, 13 Aug 2014 10:27:42 +0000 (UTC)
Received: (qmail 92559 invoked by uid 500); 13 Aug 2014 10:27:42 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 92513 invoked by uid 500); 13 Aug 2014 10:27:42 -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 92486 invoked by uid 99); 13 Aug 2014 10:27:41 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 10:27:41 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of gorkem.ercan@gmail.com
 designates 209.85.217.171 as permitted sender)
Received: from [209.85.217.171] (HELO mail-lb0-f171.google.com)
 (209.85.217.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 10:27:15 +0000
Received: by mail-lb0-f171.google.com with SMTP id l4so8159936lbv.30
        for <dev@cordova.apache.org>; Wed, 13 Aug 2014 03:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        bh=xa4QYonceXBoqULKdNXFRKVmkXNfdGNNFHlHr2sTNaY=;
        b=EpWiSHZ9+5okW02q5hlLSMYoiBUL6Oz94xw/FY40ggmdiR/vlp1SoGbJwDlUApj7Fi
         PVQtig0hKifRIH8d/h+/WfaoUy3Gbm5cRqMKaB4YGKttnlDw+9tKHE38eeFLMWgzU4HS
         16zKBPb9C+liMkBCkOs5UBEEWc6DCVzotMIhm1ZUDMD188UhRmQQBOOzq+FMFQzuDJsV
         Fd31d8yLXcVVX7svTfGDyCYplXKiAHFpjR3bxWNYWKPIBUbK6ZdvzE3MBO+o+0oFChgA
         42Ac4PRM6oqJ0TT0b8K7xLro96Xo1Dz85vA+78cfy6PtAXi2JH5ouOgYtPTNpFCtFLx5
         q4XA==
X-Received: by 10.152.205.8 with SMTP id lc8mr3529231lac.57.1407925634760;
        Wed, 13 Aug 2014 03:27:14 -0700 (PDT)
Received: from gmail.com ([88.244.168.186])
        by mx.google.com with ESMTPSA id a1sm943940lak.45.2014.08.13.03.27.12
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 13 Aug 2014 03:27:13 -0700 (PDT)
Date: Wed, 13 Aug 2014 13:27:09 +0300
From: Gorkem Ercan <gorkem.ercan@gmail.com>
To: Andrew Grieve <agrieve@google.com>
Cc: dev <dev@cordova.apache.org>,
	"kamrik@chromium.org" <kamrik@chromium.org>
Subject: Re: Feedback on "cordova plugin save" & friends
Message-ID: <20140813102709.GA95410@gmail.com>
References: 
 <CABiQX1XrHm24izqPSDXdtgj9=kDKGA4=3=Krs0OvXYLOB2MWag@mail.gmail.com>
 <20140812224347.GA92214@gmail.com>
 <CABiQX1VnKx20bm4iiMO7LN0WeVZmZ5NoFobL9dmVO9DaYXXmVQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CABiQX1VnKx20bm4iiMO7LN0WeVZmZ5NoFobL9dmVO9DaYXXmVQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Virus-Checked: Checked by ClamAV on apache.org

On Tue, Aug 12, 2014 at 09:36:34PM -0400, Andrew Grieve wrote:
> On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan <gorkem.ercan@gmail.com>
> wrote:
> 
> >
> > Just returning from PTO, great timing :)
> >
> :)
> 
> >
> > On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
> > > Played around with it and it's pretty clear to me that the ability to
> > > record your plugins & platforms in config.xml is a big step up.
> > >
> > > I do have some specific comments about the current design though:
> > >
> > > - Right now the plugin save saves all plugins to config.xml rather than
> > > just explicitly-installed plugins.
> >
> > I agree, it should only save the explicitly installed plugins but I could
> > not see an easy way to extract that info and did not want to spend too
> > much time on it at the beginning.
> >
> 
> I know that the info is stored in the android.json, ios.json, etc files,
> but I don't know how the exact details of finding it.
> @kamrik - do you know?
> 
> 
> >
> > >   - For the shrinkwrap use-case, you actually do want to record dependent
> > > plugins and their versions though, so it's still important for this case.
> >
> > agreed.
> >
> > > - Plugin restore doesn't work for locally installed plugins. e.g. try it
> > > with mobilespec. It won't remember to look in the right spot for plugins.
> > > - Really don't like that <feature> is used, since that could be confused
> > by
> > > the tools with the runtime config.xml's <feature> tag. Instead, I think
> > the
> > > syntax PGBuild uses would be better (minus the gap:)
> > > http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > >   - Note there's a PR for adding <param> (CB-7142)
> > >
> >
> > <feature> tag looks off place because CLI generates platforms specific
> > config.xml files. If CLI adopted a single config.xml file that is just
> > copied over instead of being modified during platform builds, the
> > benefit of the <feature> tag would be more visible.
> >
> > Below is what is generated by Eclipse Thym for Device plugin when it is
> > installed on config.xml, all the info for the plugin is
> > under one tag, which makes it easier to manage for humans and tools.
> >
> > <feature name="Device">
> > <param name="firefoxos-package" value="Device" />
> > <param name="android-package" value="org.apache.cordova.device.Device" />
> > <param name="ios-package" value="CDVDevice" />
> > <param name="wp-package" value="Device" />
> > <param name="id" value="org.apache.cordova.device" />
> > <param name="version" value="0.2.11" />
> > </feature>
> >
> 
> The issue I have with <feature>, is that the name="" attribute is used as
> an exec() bridge detail, and it's set by plugin.xml. Plugins can have
> multiple <feature>s, or no <feature>s at all, and there's no way to know
> the name="" before looking at the plugin.xml and inferring it. Even if CLI
> did use a shared config.xml, I think I'd still want to use <plugin>
> separate from <feature> (keep the parts that users shouldn't touch separate
> from the parts they can touch).
> 
> Plus... <feature>... what the heck is a feature? I know what a plugin is,
> and a platform, but feature (as well as <dependency>), are generic terms
> that I don't think make obvious what they do. E.g. are platforms a
> feature/dependency? <platform> and <plugin> are more self-explanatory I
> think.
> 

I agree.. <feature> is a horrible name to define plugins. I can
easily change the saved info to be in <cdv:plugin> tags, it makes little
difference and this is a convinient time to do it. I still prefer
everything related to a plugin collected under one tag perhaps we should retire
the <feature> tag and use the new one on the platform runtimes too.


> 
> 
> >
> > > When I was playing with it, I found that I wished that is would just run
> > > every time I added a plugin, rather than having to run the command
> > > explicitly afterwards. Maybe we could add an environment variable that
> > will
> > > enable it while we're still experimenting? Then, too, we could make
> > > platform / plugin restore a part of `prepare`.
> >
> > Initial implementation was actually part of the plugin add and
> > prepare. We did not have explicit save and restore commands at all.
> > Michal suggested that it was early for this feature so I came up with
> > the save and restore commands.
> >
> > On Eclipse Thym, I have it implemented so that every plugin installation
> > is "saved" to config.xml and plugins are auto restored when they are
> > detected
> > on config.xml. I am actually keeping plugins folder at this point just
> > to be compatible but I hope that we can get CLI to the same stage and
> > make the plugins folder a temporarily generated one that is not visible
> > to anyone.
> >
> 
> Cool! How to you handle <asset>s if you don't actually use the plugins/
> directory? CLI has to copy them from plugins/ -> platforms on each prepare
> when constructing the www/.

The plugins directory may still exist but not as part of the project
tree because now config.xml carries all the info needed for it to be
generated. On CLI it can probably be implemented on prepare by generating 
(or updating) a plugins folder on a temp folder as a build time artifact 
and used from there.

> 
> 
> >
> > >
> > > Don't have the intention of picking up work on this in the near term, but
> > > wanted to at least share the feedback since I did play around with it.
> >
> > No worries, as long as somebody takes time to review and merge PRs, I
> > can keep the ball rolling.
> >
> > --
> > Gorkem
> >