cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jong <>
Subject Re: config.xml refactoring
Date Wed, 28 Aug 2013 20:34:30 GMT
I think you have covered the common workflows.  Some developers will have their own workflow
but it should resemble the bin script method in the end.

What I'd like to see is the ability to have my app's user config.xml (1 per platform would
be fine) and have defaults for what is not specified there.  The user specified config.xml
takes precedence.  So when I upgrade, I just need to copy over the config.xml.

-James Jong

On Aug 28, 2013, at 2:56 PM, Michal Mocny <> wrote:

> supporting platforms/ as generated content (aka "build artifact") is
> certainly an ultimate goal, but only for the CLI workflow, and even then we
> would love to suport fallback to sane actions when users don't see it that
> way and do modify platforms/.
> Second, a single config.xml shared for all platforms, modified directly by
> the user maybe might be possible (may involve <platform> tags or just
> whitelisted tag per platform), but I'm not sure thats really what we want:
> * Plugins modify it anyway, so its not really the final version
> * When we upgrade platforms we may want to add/remove/change default
> values, so its better to separate platform defaults from user explicit
> choices
> -Michal
> On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan <>wrote:
>> We (JBoss Tools) have been playing with ideas on how to work with
>> config.xml. One thing we do right now is to have only one config.xml file,
>> we try to treat config.xml as a universal way of defining cordova
>> applications. We do not have platform versions of config,xml (l think cli
>> massages them per platform right now) but rather copy the config.xml to
>> platform directory (I guess on CLI this would be at the prepare stage) . I
>> think what the developer works with and what gets deployed in the
>> application should be same. It prevents any surprises to developer when
>> he/she is trying to debug a problem. I guess use case/requirement here is
>> not to have config.xml differences between platforms.
>> As a note we treat platforms/... directory as generated content (and
>> regenerate them when needed).
>> --
>> Gorkem
>> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson <
>>> 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]
>>> [2]
>>> [3]

View raw message