+1
That same pattern could be applied to platforms actually with an additional
version attribute:
<platform name="android" version="3.5.1">
... things like icons, splaschreens, and maybe even packaging details
go here ...
</platform>
We could also follow a similar model if we wanted to say what top level cordova
version was used to create the project by using the engine element from
plugin.xml
<engine name="cordova" version="3.5.0" />
-Chuck
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Michal Mocny
Sent: Tuesday, August 12, 2014 1:34 PM
To: dev
Cc: Gorkem Ercan
Subject: Re: Feedback on "cordova plugin save" & friends
<plugin> is nice, but why not just <dependency> as plugin.xml already uses?
config.xml and plugin.xml share lots of tags already, why fork here?
-Michal
On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <[email protected]> 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.
> - 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.
> - 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)
>
> 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`.
>
> 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.
>
