cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Lantz <cla...@microsoft.com>
Subject RE: Feedback on "cordova plugin save" & friends
Date Wed, 13 Aug 2014 20:29:00 GMT
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.ercan@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.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