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 Wed, 13 Aug 2014 01:21:24 GMT
Yes, good point - Took a look at the PR with platforms - seems like a similar concept but using
the engine element which as I think about it would probably be better anyway.

    <engine name="cordova-android" version="3.5.1"/>
    <engine name="cordova-ios" version="3.5.0"/>

More consistent with the existing plugin.xml

Would we need / want to support restoring from git repos or other non-official sources?  My
off-hand reaction is that is more useful for platform development than end-users. As long
as platforms implementations are cached somewhere outside of the project itself as they are
now it doesn't strike me that restoring from the local filesystem is needed as a perf measure


-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) 
Sent: Tuesday, August 12, 2014 4:05 PM
To:; Chuck Lantz
Subject: RE: Feedback on "cordova plugin save" & friends

Given that we are looking at decoupling engine and platform releases, there should be ways
to specify them separately, right ? In this case, I am assuming it is basically version of
cordova-cli/cordova-lib and the platform, assuming that cordova-cli can work with older platform

-----Original Message-----
From: Gorkem Ercan []
Sent: Tuesday, August 12, 2014 3:59 PM
To: Chuck Lantz
Subject: Re: Feedback on "cordova plugin save" & friends

On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> +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" />

Already had a PR [1] for saving and restoring platforms, that is MIA. Is there a specific
reason why you want engines stated expilicitly, wouldn't platforms be sufficient.


> -Chuck
> -----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?
> -Michal
> 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