cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram N (MS OPEN TECH)" <panar...@microsoft.com>
Subject Re: platforms/plugins save and restore from config.xml
Date Fri, 09 Jan 2015 21:09:28 GMT
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:clantz@microsoft.com>
Sent: ?Friday?, ?January? ?9?, ?2015 ?12?:?43? ?PM
To: dev@cordova.apache.org<mailto:dev@cordova.apache.org>
Cc: Michael Brooks<mailto:mbrooks@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:jsoref@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...

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message