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 Mon, 09 Sep 2013 16:57:17 GMT
Aside from moving some files around and changing the order of operations a
bit, the biggest change will be adding support for <platform> and
<config-file> to app.xml.  By the way, thats still called config.xml, do we
want to rename it to app.xml for 3.1?


On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson <braden@chromium.org>wrote:

> I should certainly be able to. I'm digging into a major refactoring of
> Plugman right now, though, so I'll probably want to finish that. If it's
> taking too long, though, then I'll switch gears and get this in before we
> cut 3.1.
>
> Braden
>
>
> On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> Braden, are you going to be able to take this on this week?  I think it
>> would make the upgrade from 3.0 much easier.
>>
>> -Michal
>>
>>
>> On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny <mmocny@chromium.org> wrote:
>>
>> > If you would use a different helloworld app template (which is now
>> > possible to specify in both CLI and old workflow), then the
>> pre-generatred
>> > platform config.xml template would likely be the wrong one, and thus
>> this
>> > bundling for self documentation would be a disservice.
>> >
>> > I don't see very much value in documentation for bundling the config.xml
>> > inside the platform template (when do we suspect users look at that
>> file,
>> > as apposed to whats actually generated inside their project?).  Users
>> can
>> > read what is generated after adding a platform for their specific app
>> using
>> > their chosen flow.
>> >
>> > I think that since bin/create can mush defaults.xml with app.xml for
>> both
>> > flows, it should.
>> >
>> >
>> > On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland <iclelland@chromium.org
>> >wrote:
>> >
>> >> On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson <
>> braden@chromium.org
>> >> >wrote:
>> >>
>> >> > The defaults.xml is only part of the CLI workflow, yes. It has no
>> >> relevance
>> >> > if you're not using CLI. BUT there is a complete config.xml in the
>> >> > bin/create template, and it can of course have the same values as you
>> >> would
>> >> > get from an unchanged CLI project (defaults.xml + app.xml). The
>> >> > configuration values you get from the templates should be the same
in
>> >> both
>> >> > cases, I agree completely.
>> >> >
>> >>
>> >> Yes, I think it's definitely achievable to have the complete template
>> >> config.xml be exactly what you would get (modulo whitespace / comments
>> /
>> >> etc) from installing the same sample app on the same platform with CLI.
>> >>
>> >> If we can maintain that standard, then the various files become almost
>> >> self-documenting; its easy to look at the final config.xml file in the
>> >> template to see how the pieces should fit together, and work out where
>> >> each
>> >> of the tags originally came from.
>> >>
>> >> It might be worth trying to generate the template config.xml *using*
>> cli,
>> >> just to maintain the correspondence between them.
>> >>
>> >> Ian
>> >>
>> >>
>> >> > Braden
>> >> >
>> >> >
>> >> > On Sun, Sep 8, 2013 at 5:28 AM, James Jong <wjamesjong@gmail.com>
>> >> wrote:
>> >> >
>> >> > > Andrew - what I was thinking was pretty much what Michal wrote
>> below.
>> >> > >  Perhaps it was my interpretation of the original note but I
>> thought
>> >> > > defaults was to be applied only in the CLI workflow.
>> >> > >
>> >> > > -James Jong
>> >> > >
>> >> > > On Sep 7, 2013, at 1:05 PM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>> >> > >
>> >> > > > 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