I agree with Andrew, fail loudly if we cannot find it. And, jam all this into 1 attribute which may or may not have a version ( or a tag? ) Essentially just store whatever the parameter to 'cordova plugin add' was.
@purplecabbage risingj.com On Mon, Mar 30, 2015 at 5:36 PM, Andrew Grieve <agri...@chromium.org> wrote: > I don't think we'd want to try a fallback in this case. Better to fail > loudly if the plugin can't be found where it's expected to be. > > I think since NPM uses only a single field (although theirs isn't labeled), > we should do likewise. Don't feel strongly about it though. > > On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales <eymor...@us.ibm.com> > wrote: > > > It could make sense to store both for the case where restoring from src > > fails. For example, if the path to a local folder no longer exists, what > do > > you use to restore? In that case you could use the version as a fallback? > > > > Thanks, > > Edna Morales > > > > [image: Inactive hide details for "Gorkem Ercan" ---03/30/2015 10:45:03 > > AM--- On 29 Mar 2015, at 23:11, Tim Barham wrote:]"Gorkem Ercan" > > ---03/30/2015 10:45:03 AM--- On 29 Mar 2015, at 23:11, Tim Barham > wrote: > > > > From: "Gorkem Ercan" <gorkem.er...@gmail.com> > > To: "dev [dev@cordova.apache.org]" <dev@cordova.apache.org> > > Date: 03/30/2015 10:45 AM > > Subject: Re: Question about plugin/platform --save: src vs version? > > ------------------------------ > > > > > > > > > > > > On 29 Mar 2015, at 23:11, Tim Barham wrote: > > > > > Hi - I'm looking for input on this issue: For the plugin/platform > > > --save feature, there's currently an inconsistency between how we > > > store the information in config.xml for platforms vs plugins. > > > > > > > > > > > > For platforms, we have a 'version' attribute where we store either the > > > source location or the version: if the platform was added by > > > specifying a specific location (git repository, local folder, package > > > file etc), we store that in the 'version' attribute. Otherwise we > > > store the actual version. > > > > > > > > > > > > For plugins, these two values are stored separately - source location > > > in the 'src' attribute and version in the 'version' attribute. Note > > > however that when we restore a plugin, we ignore the 'version' > > > attribute if there is a 'src' attribute. > > > > > > > > This comes from the history of the implementation ( as these things do). > > In the old experimental save implementation, we had 3 parameters, > > namely, version, url and installPath, and for every plugin we expected > > one of them to exist. During the effort for npmizing the save > > functionality the contribution for platforms and plugins were done > > separately hence the unmatching attributes. So there is no real > > technical reason for doing one way or the other and if you are willing > > to unify them that is fantastic. > > > > > > > > > > I'd like to make these consistent. My first thought was to support > > > 'version' and 'src' for platforms like we currently do for plugins. > > > But since we always ignore the version if we have a src, I'm not sure > > > we actually gain anything by doing that. Storing them in different > > > attributes is perhaps clearer, but storing both implies we make use of > > > both, which we don't. Also, the code ends up being simpler overall if > > > we just store whichever we care about in the version attribute. > > > > > > > I personally prefer to clearly label data in case user needs to > > read/modify the config.xml, seeing a git url on the version attribute > > still puzzles me. But I am fine with either way. Whatever you decide > > please remember to support/migrate the current attributes so that we do > > not end up with stale entries on config.xml > > > > > > > > > > > Any thoughts either way? > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Tim > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > >
