Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.219.53 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: <05A23401-4C21-41A1-AAC3-3BA626006581@gmail.com>
References: 
 <CAMk5LLme8qdFkvGxJ9+CKtX1kvfvG5kipzYxyyQXyo-TDmw9bQ@mail.gmail.com>
 <CADVgkyNrLHZ+3EsOq4y4s+HMsEh-CKjSmuUsUhJAd3W9UPtKHA@mail.gmail.com>
 <CAEeF2Tc_zq6OAjPCvTu1BMiQCL9Mr_RgsAVVBY9QnJ8JAk9q-w@mail.gmail.com>
 <05A23401-4C21-41A1-AAC3-3BA626006581@gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Thu, 5 Sep 2013 23:19:04 -0400
Message-ID: 
 <CAK_TSX+yNp4mDTz3jutyauxFor=XdzfVtoRDgyU9oAOGyH6ffg@mail.gmail.com>
Subject: Re: config.xml as a build artifact for less suffering and easier
 upgrades
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a9a7c74c7df04e5ae81fe

--047d7b3a9a7c74c7df04e5ae81fe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 fil=
e
> > 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.or=
g
> >>> wrote:
> >>
> >>> config.xml as a build artifact for less suffering and easier upgrades
> >>> Terminology
> >>>
> >>>   -
> >>>
> >>>   =E2=80=9Cplatform config.xml=E2=80=9D refers to the platform-specif=
ic config.xml
> >> files,
> >>>   eg. platforms/android/res/xml/config.xml. This is the final file re=
ad
> >> by
> >>>   Cordova at runtime.
> >>>   -
> >>>
> >>>   =E2=80=9Capp config.xml=E2=80=9D 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 honoure=
d.
> >>>   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. Le=
ss
> >>>   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=E2=80=99s cordova create template so that it=
s
> top-level
> >>>   app config.xml contains <name>, <author>, <content>, etc. - tags th=
e
> >>>   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 th=
e
> >>>      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=E2=80=99s 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 migh=
t
> >>> make.
> >>>      -
> >>>
> >>>         Note that this means we shouldn=E2=80=99t be needlessly setti=
ng
> 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 forma=
t
> >>>
> >>
>
>

--047d7b3a9a7c74c7df04e5ae81fe--