James, I think that sounds like what we've been thinking -- but, why do you expect to need to copy something when doing an upgrade? Is it because you think upgrade means re-creating a new workspace (which is kinda true right now)? We are hoping to support in-place upgrades, with no copies needed.
-Michal On Wed, Aug 28, 2013 at 4:34 PM, James Jong <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected] > >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 < > [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 > >>> > >> > >
