cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jong <wjamesj...@gmail.com>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Thu, 05 Sep 2013 21:16:44 GMT
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.

The new CLI prepare flow makes sense to me.

-James Jong

On Sep 5, 2013, at 2:21 PM, Michal Mocny <mmocny@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 <braden@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
>>> 
>> 


Mime
View raw message