I think either is fine. Note that as of last week, it is fine to use url#branch:subdir in dependency url values.
On Mon, Sep 9, 2013 at 1:06 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > I don't mind that but I think we should start relying on our registry > from now on. It's so much simpler to specify a name and a version than > a long url, branch and subpath. I will write tests for this specific > case this week. > > On Mon, Sep 9, 2013 at 9:05 AM, Jeffrey Heifetz <jheif...@blackberry.com> > wrote: > > So it seems I killed all discussion here, but before I did that I feel we > > reached a consensus that relative dependencies are something we'd like to > > support. The final decision to make is how we would like to do so. > > > > Current Implementation <dependency id url commit subdir />. When url = > "." > > then the dependency is treated as living in a git repo and the path is > > <gitRoot>/subdir > > > > Proposal 1: > > When url is missing entirely then the dependency is treated as > file-system > > relative and the the path is <current plugin.xml>/subdir > > > > Proposal #2 We update the dependency element to <dependency > > src=url#branch:subdir>. If you want a git relative path then url = "." > and > > for file-system relative url != "." and does not have "://" > > > > Does this seem correct to everyone? Does anyone have any strong opinions > > one way or the other? > > > > > > On 13-09-04 4:18 PM, "Jeffrey Heifetz" <jheif...@blackberry.com> wrote: > > > >>While I believe we could be able to specify everything with a single > >>parameter, I don't follow what problem we're trying to solve by doing so. > >> > >>If I understand everything correctly we're comparing the following; > >> <dependency src=url#branch:subdir /> > >> <dependency url=url commit=branch subdir=subdir /> > >> > >>While both seem reasonable and I do like the first, this seems > >>unnecessary. > >> > >>On 13-09-04 3:18 PM, "Braden Shepherdson" <bra...@chromium.org> wrote: > >> > >>>Not quite, since the checked-out directories generally don't have the > >>>".git" suffix; you'd have to override git's normal naming behavior when > >>>cloning these. > >>> > >>>I think that's quite a bit of delicate magic we don't need. I think src > >>>might be a better name, if we wanted to go with a single parameter. > >>> > >>>If we want to go with two, I like url and path. Supplying both and > >>>choosing > >>>based on where the parent plugin was fetched from, that would probably > >>>work. > >>> > >>>I think src="" and my three use cases above works. Thoughts? > >>> > >>>Braden > >>> > >>> > >>>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <agri...@chromium.org> > >>>wrote: > >>> > >>>> Here's another use-case: > >>>> - You have a github account > >>>> - You have one plugin per repo > >>>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git > >>>> - You want AppBundle to depend on > >>>> https://github.com/MobileChromeApps/zip.git > >>>> - You want this to work when you've got your plugins checked out for > >>>>local > >>>> dev: > >>>> plugins/AppBundle.git > >>>> plugins/zip.git > >>>> > >>>> You try <dependency src="zip.git" /> > >>>> > >>>> If we treated this as a relative URL, then it would actually work in > >>>>both > >>>> cases (online or checked out). If we treat non-absolute-urls as > >>>>subdirs, > >>>> then things don't work out for this use-case. If we use path= for > >>>>subdirs > >>>> and url= for repo URLs, then both use-cases work out. > >>>> > >>>> > >>>> > >>>> > >>>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mmo...@chromium.org> > >>>>wrote: > >>>> > >>>>> I'm not convinced that all use cases cannot be handled with a single > >>>>> attribute. Maybe url / path are the wrong names, maybe a single > >>>>>src="". > >>>>> > >>>>> > >>>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson > >>>>><bra...@chromium.org>wrote: > >>>>> > >>>>>> Sure, I can work with path="" instead. What happens if (when) a user > >>>>>> supplies both? > >>>>>> > >>>>>> > >>>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve > >>>>>><agri...@chromium.org>wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson < > >>>>>>> bra...@chromium.org> wrote: > >>>>>>> > >>>>>>>> I believe the current logic is "a plugin with this ID is already > >>>>>>>> installed, so stop". That interacts badly with different versions. > >>>>>>>> > >>>>>>>> Braden > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny > >>>>>>>><mmo...@chromium.org>wrote: > >>>>>>>> > >>>>>>>>> .. but either way if we add support for filesystem-relative paths > >>>>>>>>>and > >>>>>>>>> they work when fetching the original plugin either from git or > >>>>>>>>>locally, > >>>>>>>>> then we are done. > >>>>>>>>> > >>>>>>>>> As an aside, when a plugin lists its dependency as explicitly > from > >>>>>>>>>a > >>>>>>>>> git url, can the user somehow override that to install from a > >>>>>>>>>local copy? > >>>>>>>>> Perhaps if they manually install the dependant first, then we > >>>>>>>>>won't go > >>>>>>>>> fetch from git needlessly? How does that interact with different > >>>>>>>>>versions > >>>>>>>>> of the plugin? > >>>>>>>>> > >>>>>>>>> -Michal > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny > >>>>>>>>><mmo...@chromium.org>wrote: > >>>>>>>>> > >>>>>>>>>> Jeffrey's point at the start of this thread is that he isn't > >>>>>>>>>>using a > >>>>>>>>>> git repo locally, so there is no .git folder to find. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson < > >>>>>>>>>> bra...@chromium.org> wrote: > >>>>>>>>>> > >>>>>>>>>>> I like where this is generally going, but I want to correct one > >>>>>>>>>>> mistake Michal made. There /is/ a way to know which directory > >>>>>>>>>>>above a > >>>>>>>>>>> plugin is the root. The code uses git to find the .git > >>>>>>>>>>>directory, which is > >>>>>>>>>>> taken to be the root from which the subdir is relative. That > >>>>>>>>>>>means that in > >>>>>>>>>>> the case of url="." and url="https://github.com/..."; the > subdir > >>>>>>>>>>> has the same meaning: relative to the git root. > >>>>>>>>>>> > >>>>>>>>>>> I like the path="" option. I agree that subdir and ref could be > >>>>>>>>>>> dropped, since they can be specified as part of the URL. On the > >>>>>>>>>>>other hand, > >>>>>>>>>>> there's no harm in keeping them around for compatibility. > >>>>>>>>>>> > >>>>>>>>>>> I suggest: > >>>>>>>>>>> > >>>>>>>>>>> 1. Remote git, all in URL: url=" > >>>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"; > >>>>>>>>>>> 2. Remote git, separate parameters: url=" > >>>>>>>>>>> https://github.com/foo/bar.git"; subdir="sub/dir" > >>>>>>>>>>>ref="somebranch" > >>>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir" > >>>>>>>>>>> ref="somebranch" (we can probably support all-in-URL here > >>>>>>>>>>>too) > >>>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir" (no > >>>>>>>>>>> all-in-URL here; there's no need for the other parameters in > >>>>>>>>>>>this case) > >>>>>>>>>>> > >>>>>>>>>>> The last can be differentiated from the others easily enough, > >>>>>>>>>>>the > >>>>>>>>>>> logic is: > >>>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a > >>>>>>>>>>> remote git. This is already supported fully. > >>>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path. > >>>>>>>>>>> Already fully supported. > >>>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new > >>>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin, > >>>>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always > >>>>>>>>>>>required. > >>>>>>>>>>> > >>>>>>>>>> I think this will be confusing. For case #3, you have the "url" > >>>>>>> attribute that defines the path, and not the url. I would look at > >>>>>>>this and > >>>>>>> interpret it as a relative URL, and the URL is meant to tell you > >>>>>>>where the > >>>>>>> git repo is. It would be much clearer to call this "path" instead > of > >>>>>>>"url" > >>>>>>> for #3 I think. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use > / > >>>>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to > >>>>>>>>>>>properly > >>>>>>>>>>> split and convert to Windows backslashes where appropriate. I'm > >>>>>>>>>>>sure there > >>>>>>>>>>> are a few places where we've gotten this wrong; Windows users > >>>>>>>>>>>please file > >>>>>>>>>>> bugs if you run into them. Mostly, though, I was careful to > >>>>>>>>>>>split/join > >>>>>>>>>>> explicitly on / or use path.foo functions appropriately.) > >>>>>>>>>>> > >>>>>>>>>>> Thoughts on that proposal? > >>>>>>>>>>> > >>>>>>>>>>> Braden > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny > >>>>>>>>>>><mmo...@chromium.org>wrote: > >>>>>>>>>>> > >>>>>>>>>>>> For now, yes, but we could extend that without breaking > >>>>>>>>>>>>anything, > >>>>>>>>>>>> no? > >>>>>>>>>>>> Right now url="../etc" would be invalid, so we could safely > >>>>>>>>>>>>add > >>>>>>>>>>>> support > >>>>>>>>>>>> for urls with leading "..", and make that relative to current > >>>>>>>>>>>> plugin. > >>>>>>>>>>>> > >>>>>>>>>>>> url="." would still do what it does today, but could likely be > >>>>>>>>>>>> deprecated > >>>>>>>>>>>> along with subdir and commit attributes (or at least document > >>>>>>>>>>>>the > >>>>>>>>>>>> limitation of that approach somewhere). > >>>>>>>>>>>> > >>>>>>>>>>>> Not sure about making the form url="./etc" be relative to URL > >>>>>>>>>>>>root > >>>>>>>>>>>> or > >>>>>>>>>>>> current plugin, but I don't see why that form would ever be > >>>>>>>>>>>>useful > >>>>>>>>>>>> anyway. > >>>>>>>>>>>> > >>>>>>>>>>>> -Michal > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve < > >>>>>>>>>>>> agri...@chromium.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > Because for the hosted case, the URL points to where the > repo > >>>>>>>>>>>> is, not to > >>>>>>>>>>>> > where the plugin is. > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny < > >>>>>>>>>>>> mmo...@chromium.org> wrote: > >>>>>>>>>>>> > > >>>>>>>>>>>> >> If URL can be relative, why do we need a new path > parameter? > >>>>>>>>>>>> All we > >>>>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the > >>>>>>>>>>>> plugin not > >>>>>>>>>>>> >> root, which I think is fine. > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to > >>>>>>>>>>>>make > >>>>>>>>>>>> sure all > >>>>>>>>>>>> >> the cases are handled. > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve < > >>>>>>>>>>>> agri...@chromium.org>wrote: > >>>>>>>>>>>> >> > >>>>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) > that > >>>>>>>>>>>>I > >>>>>>>>>>>> think is > >>>>>>>>>>>> >>> marginally nicer: > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> url="." to be made optional, but default value is "." > >>>>>>>>>>>> >>> subdir="" works only with git repos and is always relative > >>>>>>>>>>>>to > >>>>>>>>>>>> the root > >>>>>>>>>>>> >>> of the repo. > >>>>>>>>>>>> >>> path="" works with git repos or local paths and is > relative > >>>>>>>>>>>>to > >>>>>>>>>>>> the > >>>>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or > >>>>>>>>>>>> "subdir" if you > >>>>>>>>>>>> >>> have "path". > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> Support was just added for specifying commit and path > >>>>>>>>>>>>within > >>>>>>>>>>>> url. So, we > >>>>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or > >>>>>>>>>>>> "path" > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative > >>>>>>>>>>>>to > >>>>>>>>>>>> the > >>>>>>>>>>>> >>> current plugin's git url. > >>>>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current > >>>>>>>>>>>>URL > >>>>>>>>>>>> >>> (cordova-labs style) > >>>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on > >>>>>>>>>>>>the > >>>>>>>>>>>> current URL > >>>>>>>>>>>> >>> plus a subdir within it. > >>>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you > >>>>>>>>>>>> just want to > >>>>>>>>>>>> >>> set the path) > >>>>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the > >>>>>>>>>>>>current > >>>>>>>>>>>> plugin is > >>>>>>>>>>>> >>> from git, then be careful not to go above the git root. > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny < > >>>>>>>>>>>> mmo...@chromium.org>wrote: > >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution > >>>>>>>>>>>>for > >>>>>>>>>>>> specifying > >>>>>>>>>>>> >>>> dependancies that would work regardless of where/how the > >>>>>>>>>>>> plugins are > >>>>>>>>>>>> >>>> hosted, git or local. If you had: > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> BB_PLUGINS/ > >>>>>>>>>>>> >>>> - plug1/ > >>>>>>>>>>>> >>>> - plug2/ > >>>>>>>>>>>> >>>> ... > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> (and plug1 depends on plug2), then: > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1 > >>>>>>>>>>>>..and.. > >>>>>>>>>>>> cordova > >>>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1 > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> ..should both work without changing all of the dependency > >>>>>>>>>>>> tags in plug1. > >>>>>>>>>>>> >>>> Actually, the plugin author should not have an explicit > >>>>>>>>>>>>say > >>>>>>>>>>>> in how a > >>>>>>>>>>>> >>>> user > >>>>>>>>>>>> >>>> manages these directories (except in the directory > >>>>>>>>>>>> structure). Note > >>>>>>>>>>>> >>>> that > >>>>>>>>>>>> >>>> this situation applies whenever a user clones your plugin > >>>>>>>>>>>> repo to > >>>>>>>>>>>> >>>> locally, > >>>>>>>>>>>> >>>> or for the reverse direction, when ever they add your > >>>>>>>>>>>>plugins > >>>>>>>>>>>> into their > >>>>>>>>>>>> >>>> teams' git repo. > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> Right now, thats not possible, because when installing > >>>>>>>>>>>>from > >>>>>>>>>>>> local path > >>>>>>>>>>>> >>>> with > >>>>>>>>>>>> >>>> url="." there is no way to know which of the plugins > >>>>>>>>>>>>parent > >>>>>>>>>>>> directories > >>>>>>>>>>>> >>>> to > >>>>>>>>>>>> >>>> consider as the "root". We could resolve this using > >>>>>>>>>>>>several > >>>>>>>>>>>> ways, among > >>>>>>>>>>>> >>>> them: > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path > >>>>>>>>>>>> relative to this > >>>>>>>>>>>> >>>> plugin" (note however, that I propose it also works when > >>>>>>>>>>>> installing > >>>>>>>>>>>> >>>> from a > >>>>>>>>>>>> >>>> git repo). Deprecate/warn against using url=".". > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root > >>>>>>>>>>>>dir > >>>>>>>>>>>> so we can > >>>>>>>>>>>> >>>> walk > >>>>>>>>>>>> >>>> the directory tree to find the valid target for url="." > >>>>>>>>>>>>(ie, > >>>>>>>>>>>> replace the > >>>>>>>>>>>> >>>> requirement for a .git with a requirement for a > >>>>>>>>>>>> .cordova_repo, which BB > >>>>>>>>>>>> >>>> and > >>>>>>>>>>>> >>>> others could place within their plugin bundle). > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> I like (1). > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> -Michal > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny < > >>>>>>>>>>>> mmo...@chromium.org> > >>>>>>>>>>>> >>>> wrote: > >>>>>>>>>>>> >>>> > >>>>>>>>>>>> >>>> > Sounds reasonable to me. > >>>>>>>>>>>> >>>> > > >>>>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) > >>>>>>>>>>>>shouldn't > >>>>>>>>>>>> do what > >>>>>>>>>>>> >>>> you > >>>>>>>>>>>> >>>> > request when the url for the original plugin was a > local > >>>>>>>>>>>> path? Maybe > >>>>>>>>>>>> >>>> just > >>>>>>>>>>>> >>>> > a bug? > >>>>>>>>>>>> >>>> > > >>>>>>>>>>>> >>>> > -Michal > >>>>>>>>>>>> >>>> > > >>>>>>>>>>>> >>>> > > >>>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz < > >>>>>>>>>>>> >>>> jheif...@blackberry.com>wrote: > >>>>>>>>>>>> >>>> > > >>>>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that > >>>>>>>>>>>> included some > >>>>>>>>>>>> >>>> plugins > >>>>>>>>>>>> >>>> >> and ran into a use-case not covered by the current > >>>>>>>>>>>>plugin > >>>>>>>>>>>> spec.[1] > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency > >>>>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which > >>>>>>>>>>>> plugman will > >>>>>>>>>>>> >>>> use > >>>>>>>>>>>> >>>> >> to clone down a repo and install > >>>>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a > >>>>>>>>>>>> subdir relative > >>>>>>>>>>>> >>>> to > >>>>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse > >>>>>>>>>>>>to > >>>>>>>>>>>> find the > >>>>>>>>>>>> >>>> root and > >>>>>>>>>>>> >>>> >> install from there. > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> I would like to propose a third way which would be > >>>>>>>>>>>> relative to the > >>>>>>>>>>>> >>>> >> current install and not use git at all > >>>>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir > >>>>>>>>>>>> relative to the > >>>>>>>>>>>> >>>> >> current plugin.xml. > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova > >>>>>>>>>>>> with plugins > >>>>>>>>>>>> >>>> to > >>>>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git > >>>>>>>>>>>> (considering the > >>>>>>>>>>>> >>>> plugins > >>>>>>>>>>>> >>>> >> are fully installed) > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> 1. > >>>>>>>>>>>> > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> >>>> >> > >>>>>>>>>>>> > > >>>>>>>>>>>>---------------------------------------------------------------- > >>>>>>>>>>>>- > >>>>>>>>>>>>---- > >>>>>>>>>>>> >>>> >> 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. >
