cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Thu, 05 Sep 2013 18:21:06 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message