cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <gorkem.er...@gmail.com>
Subject Re: Feedback on "cordova plugin save" & friends
Date Wed, 13 Aug 2014 10:37:06 GMT
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