cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: config.xml refactoring
Date Wed, 28 Aug 2013 18:15:21 GMT
FYI: This was a quick whiteboard discussion this morning that started with
"why do I need to modify the platform config just to update my
application's name", and sorta spiraled into an interesting idea to
potentially solve this problem once and for all.

Trying to make sure we haven't missed anything before putting the effort
into formulating it into an email.


On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson <braden@chromium.org>wrote:

> So we have several bugs[1][2][3] about fixing the handling of config.xml
> and of upgrading CLI projects. Upgrading platforms is hard because the user
> might have been modifying files in the platforms/foo directory, and we
> don't want to go overwriting them. Most of the time the file that's been
> changed is the platform's config.xml.
>
> So we (the Google team) are working on a proposal for rearranging how we
> handle config.xml files in order to make upgrades easier, and solving some
> of these other problems (splash screens) easier. Also to make the CLI
> tooling simpler, because currently the platform config.xml file is both the
> input and output of several processes (mainly adding and removing plugins,
> as well as cordova prepare).
>
> What we want to know, in writing this proposal is: what use-cases for the
> config.xml files are there? There seem to be two:
> 1. Not using CLI, just bin/create and maybe Plugman.
> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1
> with these changes to the files.
>
> Is there anything else we should be thinking about? If not, we'll have the
> proposal sent around tomorrow.
>
>
> Braden
>
> [1] https://issues.apache.org/jira/browse/CB-4624
> [2] https://issues.apache.org/jira/browse/CB-3216
> [3] https://issues.apache.org/jira/browse/CB-3571
>

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