cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Lantz <>
Subject RE: Feedback on "cordova plugin save" & friends
Date Tue, 12 Aug 2014 20:40:25 GMT

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

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


-----Original Message-----
From: [] 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?


On Tue, Aug 12, 2014 at 4:06 PM, 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.
>   - 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:)
>   - 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.
View raw message