cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <gorkem.er...@gmail.com>
Subject Re: Feedback on "cordova plugin save" & friends
Date Wed, 13 Aug 2014 10:27:09 GMT
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
> >

Mime
View raw message