Mailing-List: contact user-help@storm.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@storm.apache.org
Received-SPF: pass (nike.apache.org: domain of drew@gradientx.com designates
 209.85.216.53 as permitted sender)
MIME-Version: 1.0
Date: Sat, 14 Feb 2015 10:50:47 -0800
Message-ID: 
 <CA+B+UZsgsnmvNpmg4n+3K+g=4ydZOKM=Z9BWtDNkwoq_zO+MdQ@mail.gmail.com>
Subject: Dependency relocation/shading
From: Drew Goya <drew@gradientx.com>
To: user@storm.apache.org
Content-Type: multipart/alternative; boundary=001a11353fbcc86ca2050f10d4a3

--001a11353fbcc86ca2050f10d4a3
Content-Type: text/plain; charset=UTF-8

Hey all,  I've been running into a problem lately and I'm guessing a few of
you have as well.

As the apps we run on storm get more complex our list of dependencies has
grown pretty large.  To keep everything sane I've been digging through the
dependency tree and marking everything in the storm lib dir as provided and
locking the version.  This works most of the time but takes a lot of time
and is very error prone.  Moving between storm versions is really tricky as
this dependency shuffle has to happen all over again.

I know the team has decided to relocate/shade a few key dependencies to
prevent these collisions and give storm users more flexibility.  Have you
guys tossed around the idea of relocating/shading every storm dependency?
So the only jar in lib is the storm uber jar with no possible dependency
collision?

--001a11353fbcc86ca2050f10d4a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey all, =C2=A0I&#39;ve been running into a problem lately=
 and I&#39;m guessing a few of you have as well.<div><br></div><div>As the =
apps we run on storm get more complex our list of dependencies has grown pr=
etty large.=C2=A0 To keep everything sane I&#39;ve been digging through the=
 dependency tree and marking everything in the storm lib dir as provided an=
d locking the version.=C2=A0 This works most of the time but takes a lot of=
 time and is very error prone.=C2=A0 Moving between storm versions is reall=
y tricky as this dependency shuffle has to happen all over again.</div><div=
><br></div><div>I know the team has decided to relocate/shade a few key dep=
endencies to prevent these collisions and give storm users more flexibility=
.=C2=A0 Have you guys tossed around the idea of relocating/shading every st=
orm dependency?=C2=A0 So the only jar in lib is the storm uber jar with no =
possible dependency collision?</div></div>

--001a11353fbcc86ca2050f10d4a3--