On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan <gorkem.er...@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. > > > 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 >
