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.
<engines>
<engine name="cordova-android" version="3.5.1"/>
<engine name="cordova-ios" version="3.5.0"/>
</engines>
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 either.
-Chuck
-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH)
Sent: Tuesday, August 12, 2014 4:05 PM
To: dev@cordova.apache.org; 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 versions.
-----Original Message-----
From: Gorkem Ercan [mailto:gorkem.er...@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: mmo...@google.com [mailto:mmo...@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 <agri...@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.
> >
