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

Reply via email to