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 <mmo...@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 <bra...@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 <mmo...@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 <mmo...@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 <iclell...@chromium.org > >>>> wrote: > >>>> > >>>>> On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson < > >>> bra...@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 <wjamesj...@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 <mmo...@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 < > >>> agri...@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 < > >>> wjamesj...@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 <mmo...@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 < > >>>>>> iclell...@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 < > >>>>> mmo...@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 < > >>>>>>>>> iclell...@chromium.org > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 5:16 PM, James Jong < > >>>>> wjamesj...@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 < > >>>>> mmo...@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 < > >>>>>>>>>>>>>> bra...@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 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > >
