If the content or format of defaults.xml and the initial config.xml will be different then we should ship both -- but I don't think they will be, so I think we just ship the template with a defaults file.
-Michal On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland <iclell...@chromium.org>wrote: > On Thu, Sep 5, 2013 at 5:16 PM, James Jong <wjamesj...@gmail.com> wrote: > > > defaults.xml - Is that only used by CLI? And not used by bin/create > > scripts? > > It was bit unclear to me from the description since both were mentioned > > regarding the 2 xml files. > > > > Yes, that's the idea. If you're using the bin/create scripts, then there is > a complete "config.xml" file in the template that will be used for your new > app. This is for strict backwards compatibility with anyone's workflow that > doesn't currently include CLI. > > If you are using CLI, then we will construct a new config.xml file for you > instead, from three sources: defaults.xml, which specifies all of the > platform defaults; the various plugin.xml files, and your app's config.xml > file. The end-result should be the same, but you have a clear place to > override the defaults for your app that lives outside of your platforms > directory, and the cordova team has a clear place to set those same > defaults. > > Ian > > > > > > The new CLI prepare flow makes sense to me. > > > > -James Jong > > > > On Sep 5, 2013, at 2:21 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > > > We briefly discussed JSON and the two thoughts were: > > > > > > (1) We like it, but really what does it buy us? > > > (2) This change is at the moment 100% compatible with all current > > workflows > > > (including upgrades from 3.0->3.1), and we think that's important for > > > headache-less adoption. JSON would obviously not be. > > > > > > > > > Regarding where to store the defaults, we had thought it would be a > file > > > bundled with the platform, perhaps in bin/templates? > > > > > > -Michal > > > > > > > > > On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > >> The logic flow is much safer in this method. Where do you think > > default.xml > > >> should live? (Maybe it doesn't have to exist and defaults can just be > > vars > > >> in the logic that does the processing?) > > >> > > >> Is this our opportunity to move to JSON? > > >> > > >> > > >> On Thu, Sep 5, 2013 at 8:21 AM, Braden Shepherdson < > bra...@chromium.org > > >>> wrote: > > >> > > >>> config.xml as a build artifact for less suffering and easier upgrades > > >>> Terminology > > >>> > > >>> - > > >>> > > >>> “platform config.xml” refers to the platform-specific config.xml > > >> files, > > >>> eg. platforms/android/res/xml/config.xml. This is the final file > read > > >> by > > >>> Cordova at runtime. > > >>> - > > >>> > > >>> “app config.xml” refers to the top-level config.xml found in > > >>> www/config.xml. > > >>> > > >>> Why the current situation is suffering > > >>> > > >>> - > > >>> > > >>> Chiefly, the platforms/foo/.../config.xml files are both the input > > and > > >>> output of munging by Plugman and the user. This sucks. It makes > > >>> automatic upgrades difficult because everybody has a customized > > >>> config.xml > > >>> file in their platforms. It also makes plugin rm harder and less > > >> robust > > >>> in > > >>> CLI than it needs to be. > > >>> - > > >>> > > >>> Currently only some tags in the app config.xml are actually > honoured. > > >>> Others are ignored, and this has tripped up our users. > > >>> > > >>> > > >>> Goals > > >>> > > >>> - > > >>> > > >>> bin/create workflow is unchanged. > > >>> - > > >>> > > >>> Final content of the platform config.xml file is unchanged, though > > the > > >>> method of building it in the CLI can change. > > >>> - > > >>> > > >>> CLI workflow is unchanged, in terms of what a user types. > > >>> - > > >>> > > >>> platform config.xml stops being both input and output under CLI. > Less > > >>> munging, and easier upgrades. In short, platform config.xml files > > >> become > > >>> build artifacts. > > >>> > > >>> What we propose to do about it > > >>> > > >>> - > > >>> > > >>> First, adjust the platform template (used by bin/create) to contain > > >> two > > >>> files: > > >>> - > > >>> > > >>> defaults.xml, which is versioned, immutable, and tucked away > > >>> somewhere (only CLI accesses it) and contains only the > > >>> Cordova-specified > > >>> platform defaults, such as the preferences, any default > > >>> whitelist entries, > > >>> etc. It does NOT contain any <author>, <name> or other such > tags. > > >>> - > > >>> > > >>> platform config.xml, which is the same as it currently is, a > > >> complete > > >>> config.xml for the HelloWorld app. This means behavior is > > unchanged > > >>> for people who are not using CLI. Plugman still munges this file > > >> and > > >>> outputs back to it, same as now. > > >>> - > > >>> > > >>> Second, adjust the CLI’s cordova create template so that its > > top-level > > >>> app config.xml contains <name>, <author>, <content>, etc. - tags > the > > >>> user is likely to edit. > > >>> - > > >>> > > >>> Third, modify the CLI so that the new cordova prepare flow is: > > >>> - > > >>> > > >>> Delete the old platform config.xml. > > >>> - > > >>> > > >>> Copy the defaults.xml to config.xml. > > >>> - > > >>> > > >>> Re-run the Plugman config munging for every plugin, modifying > the > > >>> fresh platform config.xml. (The order here is deliberately > > >> undefined; > > >>> plugins should already not be relying on this.) > > >>> - > > >>> > > >>> Run the config munging for the app’s config.xml as well. > > >>> - > > >>> > > >>> This results in a freshly built, build-artifact platform > > >> config.xml. > > >>> Users should not be editing it; their top-level app config.xml > > >>> has the last > > >>> word and will override any settings the defaults or plugins > might > > >>> make. > > >>> - > > >>> > > >>> Note that this means we shouldn’t be needlessly setting > > defaults > > >>> in the app config.xml, since this might prevent plugins from > > >>> changing > > >>> things that need changing. > > >>> - > > >>> > > >>> Fourth, extend the app config.xml format so that it can have > > >>> <platform>tags, like a plugin.xml. > > >>> - > > >>> > > >>> Into this it can put platform-specific things like > splashscreens, > > >>> preferences and other things, rather than mixing these together > in > > >>> the > > >>> config. > > >>> - > > >>> > > >>> In particular, it can have <config-file> tags in the usual > format > > >>> > > >> > > > > >
