RE: Where does shaded JAR get its POM?

[Sander Verhagen]

Hi all,


Thank you very much for the answers. I learned a lot about shading, in the past 
days. I even made that PR for Consul Client (then pulled it back again, since I 
clearly needed to learn more about shaded JARs first). Thanks for the 
perspectives.

Sander.



Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove verha...@sander.com now 
and start using san...@sanderverhagen.net from now on. Please update your 
address book. Thank you!

-Original Message-
From: Richard Sand [mailto:rs...@idfconnect.com] 
Sent: Monday, September 4, 2017 13:45
To: Maven Users List 
Subject: Re: Where does shaded JAR get its POM?

Hi Sander,

Old problem, no real solution except to go multi-module.

I use the shade plugin fairly often and this has always been a quandary. 
The plugin can produce a dependency-reduced POM, but then there's no way to 
automatically deploy that with your inline maven deploy goal. You must 
explicitly use mvn deploy:deploy-file and provide alternative coordinates for 
the shaded artifact and its POM (as well as explicitly specifying the remote 
repository URL, which makes me nuts).

This problem has made me pull half my remaining hair out over the past few 
years, but the dogma is "one project, one POM", and that's the law of the land.

Making projects multi-module, once I got the hang of it, hasn't been to 
onerous. Usually what I do is I take the original POM, strip it down to make 
the "parent" pom, and then make submodules with "module-base" and "module-full" 
('full' is my homegrown term for shaded, since customers get spooked by the 
term 'shaded').

Once you're done with this effort, it is rather nice to have the shaded jars as 
their own artifact with the reduced POM.

Here's an example of a POM I lifted from a submodule for shading. I trimmed it 
down a bit but its got some transformers and relocations that you may remove.

Hope this helps!

http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
  4.0.0
  ssorest-plugin-filter-full
  SSO/Rest Servlet Filter Pluigin - Full Package

  
   com.idfconnect.ssorest.plugin
   ssorest-plugin-filter-parent
   1.6.4
  

  
   
   
com.idfconnect.ssorest.plugin
ssorest-plugin-filter-base
   

  
   


 maven-clean-plugin
 3.0.0
 
  
   
${basedir}

 *-pom.xml

   
  
 




 org.apache.maven.plugins
 maven-shade-plugin
 
  true
  
false
  false
  false
  false
  true
  
${output.name}-full-${project.version}-pom.xml

  
   
   
   
false
   
  
  
   
*:*

 META-INF/maven/**

   
  
  
   
com.google

com.idfconnect.relocated.com.google
   
   
org.apache.commons

com.idfconnect.relocated.org.apache.commons

 org.apache.commons.logging.*

   
  
 

 
 
  
   full-clear
   package
   
shade
   
   

 
  com.idfconnect.ssorest:common-tools:tests
  commons-logging:commons-logging
  junit:junit
 

   
  
 



   
  



Richard Sand | CEO
IDF Connect, Inc. <http://www.idfconnect.com/>
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651


-- Original Message ------
From: "Sander Verhagen" 
To: "Maven Users List" 
Sent: 9/4/2017 4:31:41 PM
Subject: RE: Where does shaded JAR get its POM?

>>>I don't think that's correct. One of the drawbacks with using 
>>>classifiers is that there is just ONE pom, which is used for all 
>>>artifacts.
>>
>>+1
>
>This is exactly my observation, hence the question. I believe, for this 
>use case, it'd be more useful if the shaded JAR and the dependency 
>reduced POM were installed/deployed as a separate artifact (their own 
>artifactId, rather than using the classifier system). I believe this 
>could be done with some wrangling using an execution of the Maven 
>Deploy Plugin, unless someone has a better idea? I really appreciate 
>the feedback!
>
>Sander.
>
>
>Sander Verhagen
>[  san...@sanderverhagen.net  ]
>
>NOTICE: my e-mail address has changed. Please remove 
>verha...@sander.com now and start using san...@sanderverhagen.net from 
>now on. Please update your address book. Thank you!
>
>-Original Message-
>From: Benson Margulies [mailto:bimargul...@gmail.com]
>Sent: Monday, Sept

Re: Where does shaded JAR get its POM?

[Robert Scholte]

On Mon, 04 Sep 2017 22:31:41 +0200, Sander Verhagen  
 wrote:



I don't think that's correct. One of the drawbacks with using
classifiers is that there is just ONE pom, which is used for all  
artifacts.


+1


This is exactly my observation, hence the question. I believe, for this  
use case, it'd be more useful if the shaded JAR and the dependency  
reduced POM were installed/deployed as a separate artifact (their own  
artifactId, rather than using the classifier system). I believe this  
could be done with some wrangling using an execution of the Maven Deploy  
Plugin, unless someone has a better idea? I really appreciate the  
feedback!


I can give you an idea we're thinking of:
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema

But this will have a huge impact and won't help you right now.

Robert



Sander.


Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove verha...@sander.com  
now and start using san...@sanderverhagen.net from now on. Please update  
your address book. Thank you!


-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: Monday, September 4, 2017 12:51
To: Maven Users List 
Subject: Re: Where does shaded JAR get its POM?

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar  wrote:
On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer   
wrote:



AFAIK, as soon as you use a  in a dependency, the
transitive dependencies from its POM aren't used (actually, Maven
might even not download the POM at all in this case); so you should
be OK using shaded.



I don't think that's correct. One of the drawbacks with using
classifiers is that there is just ONE pom, which is used for all  
artifacts.


+1



/Anders



Note however that, this shaded JAR still depends on Guava, SLF4J API
and Immutables, so you'll have to add explicit dependencies on those.

On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen

wrote:

> Hi list,
>
>
> Different microservices at one company often have some shared
> infrastructure, such as for Service Discovery. I'm looking to use
> the awesome Consul Client for Java (
> https://github.com/OrbitzWorldwide/consul-client), and build a
> library that our various (Maven-based Java) microservices can use.
> In order to
make
> our library not too invasive in terms of dependency resolution, I
> like
the
> idea of using Consul Client's "shaded JAR". I believe shaded JARs
> weren't really meant to be consumed by other Maven projects. But
> this may be a reasonable exception. But when you look at the output
> of such project
(like
> here:
> https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16
> .3/), you'll see a POM file with all the original dependencies,
> oblivious to
the
> shading. Is there any known pattern of dealing with that? Like:
> "POM classifiers" - I know, I made that up. I also know there's an
> option to generate a "dependency reduced POM", but what good does
> that do if I
can't
> depend on it? Should this project be generating two separate  
artifacts?

>
> (P.S.: I can certainly file an issue with the Consul Client
> project, but
I
> want to be more helpful than that, and offer a concrete suggestion
> or a
PR.)
>
> Thanks, Sander.
>
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net<mailto:san...@sanderverhagen.net>  ]
>
>



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Where does shaded JAR get its POM?

[Richard Sand]

Hi Sander,

Old problem, no real solution except to go multi-module.

I use the shade plugin fairly often and this has always been a quandary.
The plugin can produce a dependency-reduced POM, but then there's no way
to automatically deploy that with your inline maven deploy goal. You
must explicitly use mvn deploy:deploy-file and provide alternative
coordinates for the shaded artifact and its POM (as well as explicitly
specifying the remote repository URL, which makes me nuts).

This problem has made me pull half my remaining hair out over the past
few years, but the dogma is "one project, one POM", and that's the law
of the land.

Making projects multi-module, once I got the hang of it, hasn't been to
onerous. Usually what I do is I take the original POM, strip it down to
make the "parent" pom, and then make submodules with "module-base" and
"module-full" ('full' is my homegrown term for shaded, since customers
get spooked by the term 'shaded').

Once you're done with this effort, it is rather nice to have the shaded
jars as their own artifact with the reduced POM.

Here's an example of a POM I lifted from a submodule for shading. I
trimmed it down a bit but its got some transformers and relocations that
you may remove.

Hope this helps!

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
 4.0.0
 ssorest-plugin-filter-full
 SSO/Rest Servlet Filter Pluigin - Full Package

 
  com.idfconnect.ssorest.plugin
  ssorest-plugin-filter-parent
  1.6.4
 

 
  
  
   com.idfconnect.ssorest.plugin
   ssorest-plugin-filter-base
  

 
  
   
   
maven-clean-plugin
3.0.0

 
  
   ${basedir}
   
*-pom.xml
   
  
 

   

   
   
org.apache.maven.plugins
maven-shade-plugin

 true

false
 false
 false
 false
 true

${output.name}-full-${project.version}-pom.xml

 
  
  
  
   false
  
 
 
  
   *:*
   
META-INF/maven/**
   
  
 
 
  
   com.google

com.idfconnect.relocated.com.google
  
  
   org.apache.commons

com.idfconnect.relocated.org.apache.commons
   
org.apache.commons.logging.*
   
  
 




 
  full-clear
  package
  
   shade
  
  
   

 com.idfconnect.ssorest:common-tools:tests
 commons-logging:commons-logging
 junit:junit

   
  
 

   
   

  
 



Richard Sand | CEO
IDF Connect, Inc. <http://www.idfconnect.com/>
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651


-- Original Message ------
From: "Sander Verhagen" 
To: "Maven Users List" 
Sent: 9/4/2017 4:31:41 PM
Subject: RE: Where does shaded JAR get its POM?


I don't think that's correct. One of the drawbacks with using
classifiers is that there is just ONE pom, which is used for all
artifacts.


+1


This is exactly my observation, hence the question. I believe, for this
use case, it'd be more useful if the shaded JAR and the dependency
reduced POM were installed/deployed as a separate artifact (their own
artifactId, rather than using the classifier system). I believe this
could be done with some wrangling using an execution of the Maven
Deploy Plugin, unless someone has a better idea? I really appreciate
the feedback!

Sander.


Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove
verha...@sander.com now and start using san...@sanderverhagen.net from
now on. Please update your address book. Thank you!

-Original Message-----
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: Monday, September 4, 2017 12:51
To: Maven Users List 
Subject: Re: Where does shaded JAR get its POM?

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar 
wrote:

On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer 
wrote:


AFAIK, as soon as you use a  in a dependency, the
transitive dependencies from its POM aren't used (actually, Maven
might even not download the POM at all in this case); so you should
be OK using shaded.



I don't think that's correct. One of the drawbacks with using
classifiers is that there is just ONE pom, which is used for all
artifacts.


+1



/Anders



Note however that, this shaded JAR still depends on Guava, SLF4J API
and Immutables, so you'll have to add explicit dependencies on those.

On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen

wrote:

> Hi list,
>
>
> Different microservices at one company often have some shared
> infrastructure, such as for Service Discovery. I'm looking to use
> the aw

RE: Where does shaded JAR get its POM?

[Sander Verhagen]

>> I don't think that's correct. One of the drawbacks with using 
>> classifiers is that there is just ONE pom, which is used for all artifacts.
>
>+1

This is exactly my observation, hence the question. I believe, for this use 
case, it'd be more useful if the shaded JAR and the dependency reduced POM were 
installed/deployed as a separate artifact (their own artifactId, rather than 
using the classifier system). I believe this could be done with some wrangling 
using an execution of the Maven Deploy Plugin, unless someone has a better 
idea? I really appreciate the feedback!

Sander.


Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. Please remove verha...@sander.com now 
and start using san...@sanderverhagen.net from now on. Please update your 
address book. Thank you!

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Monday, September 4, 2017 12:51
To: Maven Users List 
Subject: Re: Where does shaded JAR get its POM?

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar  wrote:
> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer  wrote:
>
>> AFAIK, as soon as you use a  in a dependency, the 
>> transitive dependencies from its POM aren't used (actually, Maven 
>> might even not download the POM at all in this case); so you should 
>> be OK using shaded.
>>
>
> I don't think that's correct. One of the drawbacks with using 
> classifiers is that there is just ONE pom, which is used for all artifacts.

+1

>
> /Anders
>
>
>> Note however that, this shaded JAR still depends on Guava, SLF4J API 
>> and Immutables, so you'll have to add explicit dependencies on those.
>>
>> On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
>> 
>> wrote:
>>
>> > Hi list,
>> >
>> >
>> > Different microservices at one company often have some shared 
>> > infrastructure, such as for Service Discovery. I'm looking to use 
>> > the awesome Consul Client for Java ( 
>> > https://github.com/OrbitzWorldwide/consul-client), and build a 
>> > library that our various (Maven-based Java) microservices can use. 
>> > In order to
>> make
>> > our library not too invasive in terms of dependency resolution, I 
>> > like
>> the
>> > idea of using Consul Client's "shaded JAR". I believe shaded JARs 
>> > weren't really meant to be consumed by other Maven projects. But 
>> > this may be a reasonable exception. But when you look at the output 
>> > of such project
>> (like
>> > here:
>> > https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16
>> > .3/), you'll see a POM file with all the original dependencies, 
>> > oblivious to
>> the
>> > shading. Is there any known pattern of dealing with that? Like: 
>> > "POM classifiers" - I know, I made that up. I also know there's an 
>> > option to generate a "dependency reduced POM", but what good does 
>> > that do if I
>> can't
>> > depend on it? Should this project be generating two separate artifacts?
>> >
>> > (P.S.: I can certainly file an issue with the Consul Client 
>> > project, but
>> I
>> > want to be more helpful than that, and offer a concrete suggestion 
>> > or a
>> PR.)
>> >
>> > Thanks, Sander.
>> >
>> >
>> >
>> > Sander Verhagen
>> > [  san...@sanderverhagen.net<mailto:san...@sanderverhagen.net>  ]
>> >
>> >
>>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Where does shaded JAR get its POM?

[Benson Margulies]

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar  wrote:
> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer  wrote:
>
>> AFAIK, as soon as you use a  in a dependency, the transitive
>> dependencies from its POM aren't used (actually, Maven might even not
>> download the POM at all in this case); so you should be OK using
>> shaded.
>>
>
> I don't think that's correct. One of the drawbacks with using classifiers
> is that there is just ONE pom, which is used for all artifacts.

+1

>
> /Anders
>
>
>> Note however that, this shaded JAR still depends on Guava, SLF4J API and
>> Immutables, so you'll have to add explicit dependencies on those.
>>
>> On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
>> wrote:
>>
>> > Hi list,
>> >
>> >
>> > Different microservices at one company often have some shared
>> > infrastructure, such as for Service Discovery. I'm looking to use the
>> > awesome Consul Client for Java (
>> > https://github.com/OrbitzWorldwide/consul-client), and build a library
>> > that our various (Maven-based Java) microservices can use. In order to
>> make
>> > our library not too invasive in terms of dependency resolution, I like
>> the
>> > idea of using Consul Client's "shaded JAR". I believe shaded JARs weren't
>> > really meant to be consumed by other Maven projects. But this may be a
>> > reasonable exception. But when you look at the output of such project
>> (like
>> > here:
>> > https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/),
>> > you'll see a POM file with all the original dependencies, oblivious to
>> the
>> > shading. Is there any known pattern of dealing with that? Like: "POM
>> > classifiers" - I know, I made that up. I also know there's an option to
>> > generate a "dependency reduced POM", but what good does that do if I
>> can't
>> > depend on it? Should this project be generating two separate artifacts?
>> >
>> > (P.S.: I can certainly file an issue with the Consul Client project, but
>> I
>> > want to be more helpful than that, and offer a concrete suggestion or a
>> PR.)
>> >
>> > Thanks, Sander.
>> >
>> >
>> >
>> > Sander Verhagen
>> > [  san...@sanderverhagen.net  ]
>> >
>> >
>>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Where does shaded JAR get its POM?

[Anders Hammar]

On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer  wrote:

> AFAIK, as soon as you use a  in a dependency, the transitive
> dependencies from its POM aren't used (actually, Maven might even not
> download the POM at all in this case); so you should be OK using
> shaded.
>

I don't think that's correct. One of the drawbacks with using classifiers
is that there is just ONE pom, which is used for all artifacts.

/Anders


> Note however that, this shaded JAR still depends on Guava, SLF4J API and
> Immutables, so you'll have to add explicit dependencies on those.
>
> On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
> wrote:
>
> > Hi list,
> >
> >
> > Different microservices at one company often have some shared
> > infrastructure, such as for Service Discovery. I'm looking to use the
> > awesome Consul Client for Java (
> > https://github.com/OrbitzWorldwide/consul-client), and build a library
> > that our various (Maven-based Java) microservices can use. In order to
> make
> > our library not too invasive in terms of dependency resolution, I like
> the
> > idea of using Consul Client's "shaded JAR". I believe shaded JARs weren't
> > really meant to be consumed by other Maven projects. But this may be a
> > reasonable exception. But when you look at the output of such project
> (like
> > here:
> > https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/),
> > you'll see a POM file with all the original dependencies, oblivious to
> the
> > shading. Is there any known pattern of dealing with that? Like: "POM
> > classifiers" - I know, I made that up. I also know there's an option to
> > generate a "dependency reduced POM", but what good does that do if I
> can't
> > depend on it? Should this project be generating two separate artifacts?
> >
> > (P.S.: I can certainly file an issue with the Consul Client project, but
> I
> > want to be more helpful than that, and offer a concrete suggestion or a
> PR.)
> >
> > Thanks, Sander.
> >
> >
> >
> > Sander Verhagen
> > [  san...@sanderverhagen.net  ]
> >
> >
>

Re: Where does shaded JAR get its POM?

[Thomas Broyer]

AFAIK, as soon as you use a  in a dependency, the transitive
dependencies from its POM aren't used (actually, Maven might even not
download the POM at all in this case); so you should be OK using
shaded.
Note however that, this shaded JAR still depends on Guava, SLF4J API and
Immutables, so you'll have to add explicit dependencies on those.

On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
wrote:

> Hi list,
>
>
> Different microservices at one company often have some shared
> infrastructure, such as for Service Discovery. I'm looking to use the
> awesome Consul Client for Java (
> https://github.com/OrbitzWorldwide/consul-client), and build a library
> that our various (Maven-based Java) microservices can use. In order to make
> our library not too invasive in terms of dependency resolution, I like the
> idea of using Consul Client's "shaded JAR". I believe shaded JARs weren't
> really meant to be consumed by other Maven projects. But this may be a
> reasonable exception. But when you look at the output of such project (like
> here:
> https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/),
> you'll see a POM file with all the original dependencies, oblivious to the
> shading. Is there any known pattern of dealing with that? Like: "POM
> classifiers" - I know, I made that up. I also know there's an option to
> generate a "dependency reduced POM", but what good does that do if I can't
> depend on it? Should this project be generating two separate artifacts?
>
> (P.S.: I can certainly file an issue with the Consul Client project, but I
> want to be more helpful than that, and offer a concrete suggestion or a PR.)
>
> Thanks, Sander.
>
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net  ]
>
>

Where does shaded JAR get its POM?

[Sander Verhagen]

Hi list,


Different microservices at one company often have some shared infrastructure, 
such as for Service Discovery. I'm looking to use the awesome Consul Client for 
Java (https://github.com/OrbitzWorldwide/consul-client), and build a library 
that our various (Maven-based Java) microservices can use. In order to make our 
library not too invasive in terms of dependency resolution, I like the idea of 
using Consul Client's "shaded JAR". I believe shaded JARs weren't really meant 
to be consumed by other Maven projects. But this may be a reasonable exception. 
But when you look at the output of such project (like here: 
https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/), you'll 
see a POM file with all the original dependencies, oblivious to the shading. Is 
there any known pattern of dealing with that? Like: "POM classifiers" - I know, 
I made that up. I also know there's an option to generate a "dependency reduced 
POM", but what good does that do if I can't depend on it? Should this project 
be generating two separate artifacts?

(P.S.: I can certainly file an issue with the Consul Client project, but I want 
to be more helpful than that, and offer a concrete suggestion or a PR.)

Thanks, Sander.



Sander Verhagen
[  san...@sanderverhagen.net  ]