cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Non-Git Plugin Dependencies
Date Mon, 09 Sep 2013 17:06:07 GMT
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 <jheifetz@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" <jheifetz@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" <braden@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 <agrieve@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 <mmocny@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
>>>>><braden@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
>>>>>><agrieve@chromium.org>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>>>>> braden@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
>>>>>>>><mmocny@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
>>>>>>>>><mmocny@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
<
>>>>>>>>>> braden@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
>>>>>>>>>>><mmocny@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
<
>>>>>>>>>>>> agrieve@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 <
>>>>>>>>>>>> mmocny@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 <
>>>>>>>>>>>> agrieve@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 <
>>>>>>>>>>>> mmocny@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 <
>>>>>>>>>>>> mmocny@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 <
>>>>>>>>>>>> >>>> jheifetz@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.

Mime
View raw message