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 Thu, 12 Sep 2013 16:36:21 GMT
Trying to clarify the misunderstanding...

Jeffrey, if I understand your email, your understanding of point (4) of
bradens flow is that the app.xml is *being* munged, whereas we meant that
its the app.xml config that is *doing* the munging to the platform config.
 I think that means we both agree that app.xml should never be modified,
and it was just a miscommunication.  Am I right with that understanding?

Also, in your proposal you have plugins munging/preparing *after* app.xml
does its munging. I assume you did not do intentionally, that you had just
not considered the order important.  If it was intentional, why?  We were
thinking app.xml should be last and thus have the most "importance".


On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson <braden@chromium.org>wrote:

> I think we've gotten a bit confused. Let me try to describe again the way I
> was envisioning things.
>
> 1. If defaults.xml exists, replace platform config.xml with it.
> 2. Use plugman to add each plugin's <config-file> changes onto the platform
> config.xml.
> 3. Add in the values from the app config.xml: <name>, <author> etc., which
> it currently does, plus the proposed new <config-file> tags.
> 4. Somewhere in there, call plugman prepare to update the JS modules. This
> doesn't change or depend on config.xml at all.
>
> NB: I don't suggest anywhere that we edit the user's top-level, app
> config.xml. This is just a process for building the platform config.xml,
> and making it a pure build artifact.
>
> I also suggest that the "last word"; the file whose changes are added last,
> is the app config.xml. This allows the user the power to override any
> default or setting from a plugin.
>
> Braden
>
>
> On Wed, Sep 11, 2013 at 2:16 PM, Jeffrey Heifetz <jheifetz@blackberry.com
> >wrote:
>
> > I'd like to clarify the changes to prepare before I continue the
> > implementation.
> >
> > The current prepare flow works like this
> >         1. Call parser.update_project. This includes calling
> > parser.update_from_config which updates the platform config and resources
> > based on app config (but only handles specific tags). It also updates the
> > platform www based on app www, staging and overrides.
> >         2. Call plugman prepare (sets up JS-modules)
> >         3. Plugin config-munge (where each plugin config changes are
> > iterated
> > through)
> >
> > Braden's proposed flow (in his own words)
> >         1. Delete the old platform config.xml.
> >         2. Copy the defaults.xml to config.xml.
> >         3. 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.)
> >         4. Run the config munging for the app’s config.xml as well.
> > Where I believe #4 means the plugin config-munge.
> >
> > I'd like to propose the new flow to be the following
> >
> >         1. If defaults.xml exists, replace platform congig.xml with it
> >         2. Run a generic clobbers from app.xml to platform.xml that will
> > include
> > processing the proposed <platform> tags.
> >         3. Run plugman config munge on the platform config.xml (I believe
> > this should only add net new elements)
> >
> >         4. Call a modified parser.update_project that no longer makes
> > changes to
> > the platform config.xml
> >
> > I believe that this is complimentary with the approach Braden suggested
> > with one major change. I did not include plugin config munging on the app
> > config.xml. This is because I feel that by doing so we make the app
> > config.xml the same half build artifact half user edited mess we're
> trying
> > to solve. If the list disagrees with me I will of course implement it the
> > way Braden proposed it though.
> >
> >
> >
> > On 13-09-10 1:58 PM, "Jeffrey Heifetz" <jheifetz@blackberry.com> wrote:
> >
> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> > >
> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <tommy@devgeeks.org>
> wrote:
> > >
> > >>Then colour me excited!
> > >>
> > >>+1
> > >>
> > >>
> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> > >>
> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> > >>><tommy@devgeeks.org>wrote:
> > >>>
> > >>>> I have been following this thread with a combination of interest and
> > >>>> trepidation.
> > >>>>
> > >>>> Interest:
> > >>>>
> > >>>> Anything that works towards ./platforms being a build artefact I am
> > >>>>all
> > >>>> for. In our app, ./platforms is already a build artefact. We used
> > >>>>hooks to
> > >>>> achieve this (updating config files, copying icon / splash assets,
> > >>>>etc).
> > >>>>
> > >>>> Just a quick questionŠ I know that ./platforms/../config.xml (even
> > >>>>after a
> > >>>> `cordova build Š`) still has the old defaults for name, author, id
> > >>>>etcŠ but
> > >>>> it doesn't seem to make any difference. We don't modify
> > >>>> ./platforms/../config.xml as it seemed like the modifications to
> > >>>> ./www/config.xml (and our custom hook modifications to say
> > >>>> ./platforms/android/AndroidManifest.xml) were sufficient.
> > >>>>
> > >>>> What am I missing wrt there being differences between these files?
> > >>>>
> > >>>> Trepidation:
> > >>>>
> > >>>> Users are just starting to get a handle on how the CLI works (though
> > >>>>there
> > >>>> are still some ongoing issues that I see fairly regularly, like
> > >>>>thinking
> > >>>> they still need to use Plugman directly even with CLI created
> > >>>>projects).
> > >>>> Just worried more workflow changes yet again are going to turn
> people
> > >>>>off
> > >>>> the CLI entirely. I may be a bit "twice shy", so if it's not going
> to
> > >>>> impact users much (except for making things much better) feel free
> to
> > >>>>set
> > >>>> me straight. hehe.
> > >>>>
> > >>>> - tommy
> > >>>>
> > >>> Some clarifications:
> > >>> - Change doesn't change workflow at all
> > >>> - Change will allow user's edits to their root config.xml actually
> work
> > >>>in
> > >>> all cases
> > >>>
> > >>> Win!
> > >>>
> > >>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 10/09/2013, at 2:57 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > >>>>
> > >>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >This transmission (including any attachments) may contain confidential
> > >information, privileged material (including material protected by the
> > >solicitor-client or other applicable privileges), or constitute
> > >non-public information. Any use of this information by anyone other than
> > >the intended recipient is prohibited. If you have received this
> > >transmission in error, please immediately reply to the sender and delete
> > >this information from your system. Use, dissemination, distribution, or
> > >reproduction of this transmission by unintended recipients is not
> > >authorized and may be unlawful.
> >
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message