For a "save," Git/local would require inspection of the .fetch.json file to determine the original source - but the problem is that plugman caches so the fetch source will appear to be the filesystem in most cases. That can probably be worked around, however.
We had this exact same need for the same reasons in Visual Studio and actually used the "feature" element with a custom vs: namespace to avoid the conflicts Andrew mentioned. In retrospect, plugins or dependency would have been better. I was interested when I saw this thread since we had been talking about revising and contributing something like it. -Chuck -----Original Message----- From: Gorkem Ercan [mailto:gorkem.er...@gmail.com] Sent: Wednesday, August 13, 2014 3:37 AM To: dev@cordova.apache.org Cc: Parashuram Narasimhan (MS OPEN TECH) Subject: Re: Feedback on "cordova plugin save" & friends 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. > > >
