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 <jheif...@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" <mmo...@chromium.org> wrote: > > >Thats awesome, looking forward to it! > > > > > >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz > ><jheif...@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" <mmo...@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 > >> ><bra...@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 > >> >><jheif...@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" <jheif...@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 <agri...@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 <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 > >> >> > >>>>>>>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>>> > >> >> > >>>>>>>>>>>>> > >> >> > >>>>>>>>>>> > >> >> > >>>>>>>>>>> > >> >> > >>>>>>>>>> > >> >> > >>>>>>>>> > >> >> > >>>>>>>> > >> >> > >>>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>> > >> >> > >>>> > >> >> > >> > >> >> > > > >> >> > > > >> >> > > >>>--------------------------------------------------------------------- > >> >> > >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. >
