cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Non-Git Plugin Dependencies
Date Mon, 09 Sep 2013 18:02:29 GMT
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.kadri@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message