cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <panar...@microsoft.com>
Subject RE: Feedback on "cordova plugin save" & friends
Date Tue, 12 Aug 2014 23:05:00 GMT
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
versions. 

-----Original Message-----
From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com] 
Sent: Tuesday, August 12, 2014 3:59 PM
To: Chuck Lantz
Cc: dev@cordova.apache.org
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.

[1] https://github.com/apache/cordova-lib/pull/18


> 
> -Chuck
> 
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] 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 <agrieve@google.com> 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.
> >

Mime
View raw message