cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Fri, 06 Sep 2013 14:52:56 GMT
The template version needs to be a complete config file for the sample app,
though. You should be able to run bin/create and then build the Hello,
Cordova app immediately.

defaults.xml is supposed to be stripped right down to just the
platform-specific options which, in theory, shouldn't need to be specified
by every app.

At least that's how it works in my head :) The distinction may be less
important than I'm imagining.

Ian


On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny <mmocny@chromium.org> wrote:

> 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 <iclelland@chromium.org
> >wrote:
>
> > On Thu, Sep 5, 2013 at 5:16 PM, James Jong <wjamesjong@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message