On Wed, Aug 13, 2014 at 01:21:24AM +0000, Chuck Lantz wrote: > 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.
git repos is a good idea. Right now both plugins and engines are missing it. For the non-official sources we are bound with what CLI can support. > > -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. > > >
