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
