Saving all the time certainly would make this simpler. If we save all of the time, we can also make uninstall a part of prepare. E.g. If users edits their config.xml and removes a <plugin>, then prepare can detect that and plugman uninstall it before building. If we don't always save, then editing your config.xml wouldn't be that meaningful unless you delete & recreate platforms every time.
On Mon, Jan 12, 2015 at 10:29 PM, Gorkem Ercan <gorkem.er...@gmail.com> wrote: > > > On 12 Jan 2015, at 22:09, Andrew Grieve wrote: > > Related to this, but maybe can be discussed outside of the doc just fine: >> >> https://issues.apache.org/jira/browse/CB-4275 >> >> Right now when we add a new platform, we do a for-each on directories >> within plugins/ and add them as well. This causes all plugins to wind up >> as >> top-level plugins even when they are dependent plugins on existing >> platforms. >> >> Having plugins listed in config.xml, I think it would make sense to change >> this logic to plugin add based on plugins within config.xml rather than >> directories that exist within plugins. We could potentially still add all >> of them if no plugins are listed in config.xml for backwards compat. >> >> > Related to that, I was looking at CB-8278[1] this bug not only causes the > variables to be lost also it causes the top-level plugin info to vanish as > well. > We could also fix this problem easier too if we are saving plugins to > config.xml all the time. Which means no save command or --save. > > [1] https://issues.apache.org/jira/browse/CB-8278 > > > >> >> On Mon, Jan 12, 2015 at 9:19 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> >> 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/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5 >>>> Jnc7FU41V3-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 >>>> >>>> >>>> >>>
