Thanks for putting the doc together. Added some comments to it. On Mon, Jan 12, 2015 at 5:39 PM, Mefire O. <ommen...@microsoft.com> wrote:
> Google docs link : > https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41V3-jFc/edit > > Thanks, > Mefire > > -----Original Message----- > From: Mefire O. [mailto:ommen...@microsoft.com] > Sent: Monday, January 12, 2015 2:12 PM > To: dev@cordova.apache.org > Cc: Michael Brooks > Subject: RE: platforms/plugins save and restore from config.xml > > Here's what I propose, let me know what you think : > > 'cordova platform add' > * No -save flag, No 'autosave' setting in > project_dir/.cordova/config.json > 1. 'cordova platform add android' => restores the android > platform from config.xml. If config.xml doesn't have any android engine, > falls back to using the pinned CLI version. > * With -save flag or 'autosave' setting in > project_dir/.cordova/config.json > 1. 'cordova platform add > https://github.com/apache/cordova-android.git -save' => clones the git > repo and adds the android platform to the project, then updates config.xml > and point its version to the specified git-url. > 2. 'cordova platform add android@ > https://github.com/apache/cordova-android.git -save' => clones the git > repo and adds the android platform to the project, then updates config.xml > and point its version to the specified git-url. > 3. 'cordova platform add C:/path/to/android/platform > -save' => adds the android platform to the project, then updates config.xml > and point its version to the specified folder location. > * --Save flag is used in CLI-based workflows, and 'autosave' > (project_dir/.cordova/config.json) is used in IDE-based workflows. > > 'cordova save platforms' > In its current behavior, 'cordova save platforms' retrieves all > the platforms currently installed on the project, and saves them to > config.xml. However, unlike 'cordova save plugins', it does not save the > source of the platform (i.e: git-url, folder location), it only saves the > version. This behavior is different from the one that 'cordova save > plugins' implements. > * 'cordova save platforms' => it should retrieve the sources of > all the installed platforms from .fetch.json, and save them in config.xml. > This requires making changes to the way that 'cordova platform add' works, > it should always save the source in .fetch.json. > * In case of conflict with the config.xml, 'cordova save > platforms' should error out. The -force option shall be used if we want it > to override config.xml content. > > 'cordova restore platforms' > It reads the config.xml file and install all the platforms > specified there. > > 'cordova save' > Saves all installed platforms and plugins into config.xml > > 'cordova restore' > Restores all platforms and plugins from config.xml. similar to > 'npm install'. > > Here the link to the google docs : > > Thanks, > Mefire > > -----Original Message----- > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] > Sent: Friday, January 9, 2015 1:09 PM > To: dev@cordova.apache.org > Cc: Michael Brooks > Subject: Re: platforms/plugins save and restore from config.xml > > Regarding save - I think automatic save could be an issue for folks who > want to "try out" experimental platforms, or pick up platforms from git > URIs or master branches. What would happen in that case? May be that's is > why npm --save exists in the first place. > > Where to save - For making progress, looks like we will also have to > finalize if it will be persisted in config.xml or in package.json. Most > IDEs will not use the --save option, but may choose to directly persist in > the required file when a platform is added using a GUI. > > Regarding restore - automatic restore makes a lot of sense. Does mefire's > PR not cover that ? > > From: Chuck Lantz<mailto:cla...@microsoft.com> > Sent: ?Friday?, ?January? ?9?, ?2015 ?12?:?43? ?PM > To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> > Cc: Michael Brooks<mailto:mbro...@adobe.com> > > +1 on automating. > > That's why Mefire's PR for platform add just uses the version information > in config.xml if it is present. I think the idea behind "--save" was to > make this npm-like so that if a value is already in config.xml, then you > can also update it by specifying a different version and "saving" it. > (Similar to how "npm install cordova@4.1.2 --save" would update > package.json in the directory you're executing the command even if an > earlier version was present). He mentioned the two PRs on the "--save" for > platform earlier in the this thread. > > As an improvement it could just "save" by default if there is nothing > present in config.xml. Personally I'd always use "--save". I also agree > what we do for platforms we should likely do for plugins too. > > Now, we had originally said in a hangout that "config.xml" should contain > "app stuff" and that platform and plugin versions and preferences/params > qualified as app stuff. We could certainly go towards package.json (or > something package.json-like) since that's really what we're trying to > emulate here at the end of the day I think. However, I also thought we > said that config.xml was too engrained to move away from it (though clearly > the web as a whole is moving towards the W3C app manifest). > > If we don't use config.xml, it definitely needs to be a document at the > root level not under ".cordova" since you should clearly check it into > source control and it shouldn't be hidden. It's details about the app not > how the CLI should behave. > > -Chuck > > -----Original Message----- > From: Josh Soref [mailto:jso...@blackberry.com] > Sent: Friday, January 9, 2015 11:26 AM > To: dev@cordova.apache.org > Cc: Michael Brooks > Subject: Re: platforms/plugins save and restore from config.xml > > Leo wrote: > >I had asked some questions about save and restore a while back > > >One of my biggest questions was why would these commands be an option? > > I can't think of any reasons. > > > What I'm looking for, as soon as possible, is that Cordova 'project' > >metadata is stored logically and consistently so that the CLI and > >multiple IDEs could simultaneously work on the same project and know > >about what each other have done wrt. adding/removing > >plugins/platforms/etc. > > Seems reasonable > > >Does removing experimental advance that goal or does it, as Michal > >says, put obstacles in the path of getting there by requiring long term > >support of an incomplete and possibly confusing (more options?) solution? > > I think Michal is right. > > It probably makes more sense to integrate the code behind save/restore > into (platform|plugin) add and (something) so that it automatically just > works. > > I'm not sure offhand what 'restore' would look like in a such a model > though... > Also worth considering is the recent request for `cordova run > not-installed-platform` > > `cordova run not-installed-platform` (CB-8283) should honor the values > from `cordova platform save` > > That might be the replacement for 'restore', although it probably isn't > ideal... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
