cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Feedback on "cordova plugin save" & friends
Date Wed, 13 Aug 2014 01:36:34 GMT
On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan <>

> 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:)
> >
> >   - 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

> > 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/.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message