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 Fri, 06 Sep 2013 15:06:27 GMT
I thought we were adding support for the last bit (ie, app generic not
platform specific preferences) to "app.xml" which the helloworld template
should ship with and bin/create should apply.

-Michal



On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland <iclelland@chromium.org>wrote:

> 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