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
