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 Sat, 07 Sep 2013 17:05:20 GMT
With this proposal as it stands, I think that is already true (at least for
the initial contents, obviously user can make edits later).

Ie, defaults.xml + app.xml = initial config.xml for both cases, which use
the same helloworld template's app.xml.

If there are specific differences to the default values that we want, we
maybe will want to use a different app.xml for each, but defaults.xml
should be tied to a platform-version not to a workflow.

-Michal


On Sat, Sep 7, 2013 at 7:56 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> James - that's a nice goal, but I don't think it's feasible. Did you have a
> way to do that in mind?
>
>
> On Fri, Sep 6, 2013 at 10:31 PM, James Jong <wjamesjong@gmail.com> wrote:
>
> > I would like to see the defaults be applied in all cases.  For
> > consistency, less confusion, and easier documentation.  If we add or
> change
> > the defaults in a release, both workflows should get it.  In my mind, the
> > CLI platform config.xml should be equivalent to the bin/create one.
> >
> > -James Jong
> >
> > On Sep 6, 2013, at 11:06 AM, Michal Mocny <mmocny@chromium.org> wrote:
> >
> > > 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