You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Braden Shepherdson <br...@chromium.org> on 2013/09/05 17:21:04 UTC

config.xml as a build artifact for less suffering and easier upgrades

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

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Brian LeRoux <b...@brian.io>.

I think this is the pragmatic way. Perhaps our path to JSON support will be
some soft of analogue to the XML (so either works). This is more for future
friendliness than anything else. Given Chrome apps, FxOS apps, etc it would
appear manifests are going JSON. But whatever!

Anyhow, thanks for the thought going into this guys. Definitely
cleaner/saner.


On Thu, Sep 5, 2013 at 11:21 AM, Michal Mocny <mm...@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
> > >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Anis KADRI <an...@gmail.com>.

Sure. It's a step in the right direction (having platforms/ as real
build artifacts). I would rename `defaults.xml` to `cordova.xml`
personnally but it doesn't really matter.

Users should not touch platforms/ at all and if they need to modify
anything native they should be acting on plugins. Please chime in on
the "What's your daily workflow for cordova development?" thread.



On Thu, Sep 5, 2013 at 2:16 PM, James Jong <wj...@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.
>
> The new CLI prepare flow makes sense to me.
>
> -James Jong
>
> On Sep 5, 2013, at 2:21 PM, Michal Mocny <mm...@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
>>>>
>>>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Ian Clelland <ic...@google.com>.

On Tue, Oct 8, 2013 at 10:27 AM, Jeffrey Heifetz <jh...@blackberry.com>wrote:

> So I'm not sure if we ever came to a true consensus about this, but the
> code has been up for a while now [1]. If there are no complaints in say
> 24hrs I think its reasonable to merge it in.
>

Hooray for lazy consensus! :)

Seriously, though, this is great -- I looked at the code in reviewboard a
couple of times, and it looked good. I wasn't confident enough to hit the
"Ship it" button, I guess.

I've hit a snag running CLI today, though. It looks like the new prepare
method always:
 1) runs plugman prepare for each installed plugin, which copies the plugin
js modules into the platform www dir, and then
 2) calls parser.update_project(), which deletes the platform www dir, and
recreates it.

The end result is that plugin native code is installed, but JS code is not.

I've sent up a small change to reviewboard[1]; it's working for me now for
Android and iOS -- let me know if you think it's going to introduce any new
problems, though.

Ian

[1] https://reviews.apache.org/r/14621/


> Cheers,
>
> Jeff
>
>
>
> 1. https://reviews.apache.org/r/14376/
>
> On 13-09-16 5:06 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >I've emailed github about that in the past.  Hopefully they can address
> >it,
> >since their review system is far superior for all other reasons.
> >
> >
> >On Mon, Sep 16, 2013 at 1:16 PM, Andrew Grieve <ag...@chromium.org>
> >wrote:
> >
> >> We do get emails for some pull requests, but some repos aren't set up to
> >> email and looks like CLI is one of them. Think you need to file an INFRA
> >> ticket to fix it :(.
> >>
> >> I'm liking reviewboard more than github for reviews since it lets you
> >> review your comments without sending an email for each and every one of
> >> them. I'm fine with using github as well though since that's what most
> >> people tend to use.
> >>
> >>
> >> On Mon, Sep 16, 2013 at 4:06 PM, Michal Mocny <mm...@chromium.org>
> >>wrote:
> >>
> >> > We don't get email notified (or, at least I don't) of github pull
> >> requests,
> >> > but we do get emails for review-board (or at least the assignee
> >>does?).
> >> >  Either way, if you post a link you'll likely get better luck with a
> >> review
> >> > quicker next time, sorry that we missed it.  I can't peek until
> >> > tomorrow/wed, so if no one gets to it, I'll do it then.
> >> >
> >> > -Michal
> >> >
> >> > On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
> >> > <jh...@blackberry.com>wrote:
> >> >
> >> > > So I believe this pull request is ready to go, however I have yet to
> >> get
> >> > > any feedback on the request itself. Can anyone familiar with the
> >>other
> >> > > platforms volunteer to test this with them?
> >> > >
> >> > > Is this a question of presentation, should I close the github pull
> >> > request
> >> > > in favour of the cordova review board ?
> >> > >
> >> > > On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >> > >
> >> > > >Thats awesome, looking forward to it!
> >> > > >
> >> > > >
> >> > > >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
> >> > > ><jh...@blackberry.com>wrote:
> >> > > >
> >> > > >> Yup I'm on the same page with you Michal, and I believe Braden as
> >> > well.
> >> > > >> I'm sorry I should have said so earlier, we resolved this on
> >>irc. I
> >> > > >>have a
> >> > > >> basic implementation here
> >> > https://github.com/apache/cordova-cli/pull/39
> >> > > >> but I'm still testing it.
> >> > > >>
> >> > > >> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org>
> wrote:
> >> > > >>
> >> > > >> >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
> >> > > >> ><br...@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
> >> > > >> >> > >>><to...@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
> >> > > >> >> > >>>>>>>>>><wj...@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.
> >> > > >> >> >
> >> > > >> >>
> >> > > >>
> >> > > >>
> >> ---------------------------------------------------------------------
> >> > > >> 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.
> >> > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> 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.
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Jeffrey Heifetz <jh...@blackberry.com>.

So I'm not sure if we ever came to a true consensus about this, but the
code has been up for a while now [1]. If there are no complaints in say
24hrs I think its reasonable to merge it in.

Cheers,

Jeff



1. https://reviews.apache.org/r/14376/

On 13-09-16 5:06 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>I've emailed github about that in the past.  Hopefully they can address
>it,
>since their review system is far superior for all other reasons.
>
>
>On Mon, Sep 16, 2013 at 1:16 PM, Andrew Grieve <ag...@chromium.org>
>wrote:
>
>> We do get emails for some pull requests, but some repos aren't set up to
>> email and looks like CLI is one of them. Think you need to file an INFRA
>> ticket to fix it :(.
>>
>> I'm liking reviewboard more than github for reviews since it lets you
>> review your comments without sending an email for each and every one of
>> them. I'm fine with using github as well though since that's what most
>> people tend to use.
>>
>>
>> On Mon, Sep 16, 2013 at 4:06 PM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>> > We don't get email notified (or, at least I don't) of github pull
>> requests,
>> > but we do get emails for review-board (or at least the assignee
>>does?).
>> >  Either way, if you post a link you'll likely get better luck with a
>> review
>> > quicker next time, sorry that we missed it.  I can't peek until
>> > tomorrow/wed, so if no one gets to it, I'll do it then.
>> >
>> > -Michal
>> >
>> > On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
>> > <jh...@blackberry.com>wrote:
>> >
>> > > So I believe this pull request is ready to go, however I have yet to
>> get
>> > > any feedback on the request itself. Can anyone familiar with the
>>other
>> > > platforms volunteer to test this with them?
>> > >
>> > > Is this a question of presentation, should I close the github pull
>> > request
>> > > in favour of the cordova review board ?
>> > >
>> > > On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>> > >
>> > > >Thats awesome, looking forward to it!
>> > > >
>> > > >
>> > > >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
>> > > ><jh...@blackberry.com>wrote:
>> > > >
>> > > >> Yup I'm on the same page with you Michal, and I believe Braden as
>> > well.
>> > > >> I'm sorry I should have said so earlier, we resolved this on
>>irc. I
>> > > >>have a
>> > > >> basic implementation here
>> > https://github.com/apache/cordova-cli/pull/39
>> > > >> but I'm still testing it.
>> > > >>
>> > > >> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>> > > >>
>> > > >> >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
>> > > >> ><br...@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
>> > > >> >> > >>><to...@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
>> > > >> >> > >>>>>>>>>><wj...@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.
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> 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.
>> > >
>> >
>>

---------------------------------------------------------------------
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.

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

I've emailed github about that in the past.  Hopefully they can address it,
since their review system is far superior for all other reasons.


On Mon, Sep 16, 2013 at 1:16 PM, Andrew Grieve <ag...@chromium.org> wrote:

> We do get emails for some pull requests, but some repos aren't set up to
> email and looks like CLI is one of them. Think you need to file an INFRA
> ticket to fix it :(.
>
> I'm liking reviewboard more than github for reviews since it lets you
> review your comments without sending an email for each and every one of
> them. I'm fine with using github as well though since that's what most
> people tend to use.
>
>
> On Mon, Sep 16, 2013 at 4:06 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > We don't get email notified (or, at least I don't) of github pull
> requests,
> > but we do get emails for review-board (or at least the assignee does?).
> >  Either way, if you post a link you'll likely get better luck with a
> review
> > quicker next time, sorry that we missed it.  I can't peek until
> > tomorrow/wed, so if no one gets to it, I'll do it then.
> >
> > -Michal
> >
> > On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
> > <jh...@blackberry.com>wrote:
> >
> > > So I believe this pull request is ready to go, however I have yet to
> get
> > > any feedback on the request itself. Can anyone familiar with the other
> > > platforms volunteer to test this with them?
> > >
> > > Is this a question of presentation, should I close the github pull
> > request
> > > in favour of the cordova review board ?
> > >
> > > On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >
> > > >Thats awesome, looking forward to it!
> > > >
> > > >
> > > >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
> > > ><jh...@blackberry.com>wrote:
> > > >
> > > >> Yup I'm on the same page with you Michal, and I believe Braden as
> > well.
> > > >> I'm sorry I should have said so earlier, we resolved this on irc. I
> > > >>have a
> > > >> basic implementation here
> > https://github.com/apache/cordova-cli/pull/39
> > > >> but I'm still testing it.
> > > >>
> > > >> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > >>
> > > >> >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
> > > >> ><br...@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
> > > >> >> > >>><to...@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
> > > >> >> > >>>>>>>>>><wj...@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.
> > > >> >> >
> > > >> >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> 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.
> > >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Andrew Grieve <ag...@chromium.org>.

We do get emails for some pull requests, but some repos aren't set up to
email and looks like CLI is one of them. Think you need to file an INFRA
ticket to fix it :(.

I'm liking reviewboard more than github for reviews since it lets you
review your comments without sending an email for each and every one of
them. I'm fine with using github as well though since that's what most
people tend to use.


On Mon, Sep 16, 2013 at 4:06 PM, Michal Mocny <mm...@chromium.org> wrote:

> We don't get email notified (or, at least I don't) of github pull requests,
> but we do get emails for review-board (or at least the assignee does?).
>  Either way, if you post a link you'll likely get better luck with a review
> quicker next time, sorry that we missed it.  I can't peek until
> tomorrow/wed, so if no one gets to it, I'll do it then.
>
> -Michal
>
> On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
> <jh...@blackberry.com>wrote:
>
> > So I believe this pull request is ready to go, however I have yet to get
> > any feedback on the request itself. Can anyone familiar with the other
> > platforms volunteer to test this with them?
> >
> > Is this a question of presentation, should I close the github pull
> request
> > in favour of the cordova review board ?
> >
> > On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >
> > >Thats awesome, looking forward to it!
> > >
> > >
> > >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
> > ><jh...@blackberry.com>wrote:
> > >
> > >> Yup I'm on the same page with you Michal, and I believe Braden as
> well.
> > >> I'm sorry I should have said so earlier, we resolved this on irc. I
> > >>have a
> > >> basic implementation here
> https://github.com/apache/cordova-cli/pull/39
> > >> but I'm still testing it.
> > >>
> > >> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >>
> > >> >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
> > >> ><br...@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" <jh...@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
> > >> >> > >>><to...@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
> > >> >> > >>>>>>>>>><wj...@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.
> > >> >> >
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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.
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

We don't get email notified (or, at least I don't) of github pull requests,
but we do get emails for review-board (or at least the assignee does?).
 Either way, if you post a link you'll likely get better luck with a review
quicker next time, sorry that we missed it.  I can't peek until
tomorrow/wed, so if no one gets to it, I'll do it then.

-Michal

On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
<jh...@blackberry.com>wrote:

> So I believe this pull request is ready to go, however I have yet to get
> any feedback on the request itself. Can anyone familiar with the other
> platforms volunteer to test this with them?
>
> Is this a question of presentation, should I close the github pull request
> in favour of the cordova review board ?
>
> On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >Thats awesome, looking forward to it!
> >
> >
> >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
> ><jh...@blackberry.com>wrote:
> >
> >> Yup I'm on the same page with you Michal, and I believe Braden as well.
> >> I'm sorry I should have said so earlier, we resolved this on irc. I
> >>have a
> >> basic implementation here https://github.com/apache/cordova-cli/pull/39
> >> but I'm still testing it.
> >>
> >> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >>
> >> >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
> >> ><br...@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" <jh...@blackberry.com>
> >> >>wrote:
> >> >> >
> >> >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> >> >> > >
> >> >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org>
> >> >> wrote:
> >> >> > >
> >> >> > >>Then colour me excited!
> >> >> > >>
> >> >> > >>+1
> >> >> > >>
> >> >> > >>
> >> >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org>
> >> >> wrote:
> >> >> > >>
> >> >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> >> >> > >>><to...@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 <mm...@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
> >> >> > >>>>>>>>>><wj...@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.
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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.
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Jeffrey Heifetz <jh...@blackberry.com>.

So I believe this pull request is ready to go, however I have yet to get
any feedback on the request itself. Can anyone familiar with the other
platforms volunteer to test this with them?

Is this a question of presentation, should I close the github pull request
in favour of the cordova review board ?

On 13-09-12 2:13 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>Thats awesome, looking forward to it!
>
>
>On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
><jh...@blackberry.com>wrote:
>
>> Yup I'm on the same page with you Michal, and I believe Braden as well.
>> I'm sorry I should have said so earlier, we resolved this on irc. I
>>have a
>> basic implementation here https://github.com/apache/cordova-cli/pull/39
>> but I'm still testing it.
>>
>> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>>
>> >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
>> ><br...@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" <jh...@blackberry.com>
>> >>wrote:
>> >> >
>> >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
>> >> > >
>> >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org>
>> >> wrote:
>> >> > >
>> >> > >>Then colour me excited!
>> >> > >>
>> >> > >>+1
>> >> > >>
>> >> > >>
>> >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org>
>> >> wrote:
>> >> > >>
>> >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
>> >> > >>><to...@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 <mm...@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
>> >> > >>>>>>>>>><wj...@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.
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> 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.

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

Thats awesome, looking forward to it!


On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
<jh...@blackberry.com>wrote:

> Yup I'm on the same page with you Michal, and I believe Braden as well.
> I'm sorry I should have said so earlier, we resolved this on irc. I have a
> basic implementation here https://github.com/apache/cordova-cli/pull/39
> but I'm still testing it.
>
> On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >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
> ><br...@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" <jh...@blackberry.com>
> >>wrote:
> >> >
> >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> >> > >
> >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org>
> >> wrote:
> >> > >
> >> > >>Then colour me excited!
> >> > >>
> >> > >>+1
> >> > >>
> >> > >>
> >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >> > >>
> >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> >> > >>><to...@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 <mm...@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
> >> > >>>>>>>>>><wj...@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.
> >> >
> >>
>
> ---------------------------------------------------------------------
> 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.
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Jeffrey Heifetz <jh...@blackberry.com>.

Yup I'm on the same page with you Michal, and I believe Braden as well.
I'm sorry I should have said so earlier, we resolved this on irc. I have a
basic implementation here https://github.com/apache/cordova-cli/pull/39
but I'm still testing it.

On 13-09-12 12:36 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>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
><br...@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" <jh...@blackberry.com>
>>wrote:
>> >
>> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
>> > >
>> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org>
>> wrote:
>> > >
>> > >>Then colour me excited!
>> > >>
>> > >>+1
>> > >>
>> > >>
>> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> > >>
>> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
>> > >>><to...@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 <mm...@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
>> > >>>>>>>>>><wj...@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.
>> >
>>

---------------------------------------------------------------------
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.

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <br...@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" <jh...@blackberry.com> wrote:
> >
> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> > >
> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org>
> wrote:
> > >
> > >>Then colour me excited!
> > >>
> > >>+1
> > >>
> > >>
> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > >>
> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> > >>><to...@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 <mm...@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
> > >>>>>>>>>><wj...@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.
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Braden Shepherdson <br...@chromium.org>.

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 <jh...@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" <jh...@blackberry.com> wrote:
>
> >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> >
> >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org> wrote:
> >
> >>Then colour me excited!
> >>
> >>+1
> >>
> >>
> >>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >>
> >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> >>><to...@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 <mm...@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 <mm...@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 <mm...@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
> >>>>>>>>>><wj...@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 <mm...@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.
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Jeffrey Heifetz <jh...@blackberry.com>.

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" <jh...@blackberry.com> wrote:

>Issue Created - https://issues.apache.org/jira/browse/CB-4774
>
>On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org> wrote:
>
>>Then colour me excited!
>>
>>+1
>>
>>
>>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org> wrote:
>>
>>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
>>><to...@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 <mm...@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 <mm...@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 <mm...@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
>>>>>>>>>><wj...@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 <mm...@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.

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Jeffrey Heifetz <jh...@blackberry.com>.

Issue Created - https://issues.apache.org/jira/browse/CB-4774

On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org> wrote:

>Then colour me excited!
>
>+1
>
>
>On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
>><to...@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 <mm...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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.

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Tommy-Carlos Williams <to...@devgeeks.org>.

Then colour me excited!

+1


On 10/09/2013, at 11:27 PM, Andrew Grieve <ag...@chromium.org> wrote:

> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams <to...@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 <mm...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Andrew Grieve <ag...@chromium.org>.

On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams <to...@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 <mm...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Tommy-Carlos Williams <to...@devgeeks.org>.

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





On 10/09/2013, at 2:57 AM, Michal Mocny <mm...@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 <br...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <br...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>
>> >> > > >>>>>>
>> >> > > >>>>>
>> >> > > >>>
>> >> > > >>>
>> >> > > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Braden Shepherdson <br...@chromium.org>.

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 <mm...@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 <mm...@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 <wj...@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 <mm...@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 <mm...@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
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>>
> >> > > >>>>>
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <mm...@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 <ic...@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 <wj...@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 <mm...@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 <wj...@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 <mm...@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
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>>
>> > > >>>>>
>> > > >>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <ic...@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 <wj...@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 <mm...@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 <ag...@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 <wj...@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 <mm...@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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Ian Clelland <ic...@chromium.org>.

On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson <br...@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 <wj...@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 <mm...@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 <ag...@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 <wj...@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 <mm...@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 <mm...@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 <mm...@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
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Braden Shepherdson <br...@chromium.org>.

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.

Braden


On Sun, Sep 8, 2013 at 5:28 AM, James Jong <wj...@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 <mm...@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 <ag...@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 <wj...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by James Jong <wj...@gmail.com>.

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 <mm...@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 <ag...@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 <wj...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <ag...@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 <wj...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Andrew Grieve <ag...@chromium.org>.

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 <wj...@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 <mm...@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 <mm...@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 <wj...@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 <mm...@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
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by James Jong <wj...@gmail.com>.

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 <mm...@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 <ic...@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 <mm...@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 <wj...@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 <mm...@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
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <ic...@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 <mm...@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 <wj...@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 <mm...@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
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Ian Clelland <ic...@chromium.org>.

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 <mm...@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 <wj...@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 <mm...@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
> > > >>>
> > > >>
> > >
> > >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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 <ic...@chromium.org>wrote:

> On Thu, Sep 5, 2013 at 5:16 PM, James Jong <wj...@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 <mm...@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
> > >>>
> > >>
> >
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Ian Clelland <ic...@chromium.org>.

On Thu, Sep 5, 2013 at 5:16 PM, James Jong <wj...@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 <mm...@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
> >>>
> >>
>
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by James Jong <wj...@gmail.com>.

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.

The new CLI prepare flow makes sense to me.

-James Jong

On Sep 5, 2013, at 2:21 PM, Michal Mocny <mm...@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
>>> 
>>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Michal Mocny <mm...@chromium.org>.

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
> >
>

Re: config.xml as a build artifact for less suffering and easier upgrades

Posted by Brian LeRoux <b...@brian.io>.

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 <br...@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
>