cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Sat, 07 Sep 2013 11:56:02 GMT
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