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 <[email protected]>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 >
