Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of anders.g.hammar@gmail.com
 designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
Sender: anders.g.hammar@gmail.com
In-Reply-To: <0c0b01cea9e6$f8e6a380$eab3ea80$@idfconnect.com>
References: <0a2b01cea931$7de38f00$79aaad00$@idfconnect.com>
	<CAKDUN1tKmcxYvfEn3dg1ToBymi44fe5eb-w0vxK0bpdARicBAQ@mail.gmail.com>
	<0c0b01cea9e6$f8e6a380$eab3ea80$@idfconnect.com>
Date: Thu, 5 Sep 2013 08:18:27 +0200
Message-ID: 
 <CAKDUN1vUo-huZd+f8DgfRQVLzritiVk+1u1pZJxy24sbwrxr8A@mail.gmail.com>
Subject: Re: shade plugin usage
From: Anders Hammar <anders@hammar.net>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bb04822dcf88804e59ce32c

--047d7bb04822dcf88804e59ce32c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Help the Java community kill all =FCberjars...

/Anders


On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand <rsand@idfconnect.com> wrote:

> Hi Anders - thanks for your reply. I agree with your advice - for this
> particular project artifact is a case where we want to offer both options=
,
> and the uberjar is mainly an aggregation of our product apis. But I
> definitely understand the danger you are describing.
>
> -Richard
>
>
> -----Original Message-----
> From: anders.g.hammar@gmail.com [mailto:anders.g.hammar@gmail.com] On
> Behalf
> Of Anders Hammar
> Sent: Wednesday, September 04, 2013 2:08 AM
> To: Maven Users List
> Subject: Re: shade plugin usage
>
> First, try to stay away from the =FCberjar path. It's normally not the wa=
y to
> go today, but you should use the jar and it's dependencies instead. I've
> seen many case where people use a =FCberjar just to try to make their lif=
e
> simpler but ending up with other issues instead. A proper classpath is th=
e
> way to go in my opinion.
>
> I guess your approach of deploying the =FCberjar and a dep-reduced-pom wo=
uld
> work, but please remember to deploy it to your remote repo as well (and n=
ot
> just your local repo). Somewhere in the back of my head I recall a simila=
r
> discussion earlier. Not sure if someone brought up any issues though.
> Having said that, the reason for deploying the =FCberjar at a separate
> coordinate would be to have a separate pom with reduced deps. This
> indicates
> that you plan on use the pom to get the dependencies and in that case you
> should try to stick with the original jar instead and work with the prope=
r
> set of deps.
>
> /Anders
>
>
> On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand <rsand@idfconnect.com> wrote=
:
>
> > I've a project that uses shade to create an uberjar - since I want
> > that uberjar artifact to be available for use in other projects, does
> > it make sense to *not* attach the artifact in shade, but rather have
> > shade create the uberjar and dependency-reduced-pom, and then use
> > install:install-file to grab the uberjar and drp.xml and install with
> > a new unique artifactid (as opposed to a classifier of the original
> > artifact)?
> >
> > Still feeling my way down the Maven Way...
> >
> > -Richard
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--047d7bb04822dcf88804e59ce32c--