Where does shaded JAR get its POM?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[  [hidden email]<mailto:[hidden email]>  ]

Reply | Threaded
Open this post in threaded view
|

Re: Where does shaded JAR get its POM?

Thomas Broyer-2
AFAIK, as soon as you use a <classifier> 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
<classifier>shaded</classifier>.
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 <[hidden email]>
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
> [  [hidden email]<mailto:[hidden email]>  ]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Where does shaded JAR get its POM?

Anders Hammar
On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]> wrote:

> AFAIK, as soon as you use a <classifier> 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
> <classifier>shaded</classifier>.
>

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 <[hidden email]>
> 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
> > [  [hidden email]<mailto:[hidden email]>  ]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Where does shaded JAR get its POM?

Benson Margulies
On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <[hidden email]> wrote:

> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]> wrote:
>
>> AFAIK, as soon as you use a <classifier> 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
>> <classifier>shaded</classifier>.
>>
>
> 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 <[hidden email]>
>> 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
>> > [  [hidden email]<mailto:[hidden email]>  ]
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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
[hidden email]  ]

NOTICE: my e-mail address has changed. Please remove [hidden email] now and start using [hidden email] from now on. Please update your address book. Thank you!

-----Original Message-----
From: Benson Margulies [mailto:[hidden email]]
Sent: Monday, September 4, 2017 12:51
To: Maven Users List <[hidden email]>
Subject: Re: Where does shaded JAR get its POM?

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <[hidden email]> wrote:

> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]> wrote:
>
>> AFAIK, as soon as you use a <classifier> 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 <classifier>shaded</classifier>.
>>
>
> 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
>> <[hidden email]>
>> 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
>> > [  [hidden email]<mailto:[hidden email]>  ]
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

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!

<project xmlns="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">
  <modelVersion>4.0.0</modelVersion>
  <artifactId>ssorest-plugin-filter-full</artifactId>
  <name>SSO/Rest Servlet Filter Pluigin - Full Package</name>

  <parent>
   <groupId>com.idfconnect.ssorest.plugin</groupId>
   <artifactId>ssorest-plugin-filter-parent</artifactId>
   <version>1.6.4</version>
  </parent>

  <dependencies>
   <!-- Pull in the module-base -->
   <dependency>
    <groupId>com.idfconnect.ssorest.plugin</groupId>
    <artifactId>ssorest-plugin-filter-base</artifactId>
   </dependency>

  <build>
   <plugins>
    <!-- Maven Clean Plugin to remove old DRP files -->
    <plugin>
     <artifactId>maven-clean-plugin</artifactId>
     <version>3.0.0</version>
     <configuration>
      <filesets>
       <fileset>
        <directory>${basedir}</directory>
        <includes>
         <include>*-pom.xml</include>
        </includes>
       </fileset>
      </filesets>
     </configuration>
    </plugin>

    <!-- BEGIN SHADE -->
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-shade-plugin</artifactId>
     <configuration>
      <createDependencyReducedPom>true</createDependencyReducedPom>

<keepDependenciesWithProvidedScope>false</keepDependenciesWithProvidedScope>
      <minimizeJar>false</minimizeJar>
      <shadedArtifactAttached>false</shadedArtifactAttached>
      <useBaseVersion>false</useBaseVersion>
      <promoteTransitiveDependencies>true</promoteTransitiveDependencies>

<dependencyReducedPomLocation>${output.name}-full-${project.version}-pom.xml</dependencyReducedPomLocation>

      <transformers>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
/>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ApacheLicenseResourceTransformer"
/>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformer">
        <addHeader>false</addHeader>
       </transformer>
      </transformers>
      <filters>
       <filter>
        <artifact>*:*</artifact>
        <excludes>
         <exclude>META-INF/maven/**</exclude>
        </excludes>
       </filter>
      </filters>
      <relocations>
       <relocation>
        <pattern>com.google</pattern>

<shadedPattern>com.idfconnect.relocated.com.google</shadedPattern>
       </relocation>
       <relocation>
        <pattern>org.apache.commons</pattern>

<shadedPattern>com.idfconnect.relocated.org.apache.commons</shadedPattern>
        <excludes>
         <exclude>org.apache.commons.logging.*</exclude>
        </excludes>
       </relocation>
      </relocations>
     </configuration>

     <!-- EXECUTIONS -->
     <executions>
      <execution>
       <id>full-clear</id>
       <phase>package</phase>
       <goals>
        <goal>shade</goal>
       </goals>
       <configuration>
        <artifactSet>
         <excludes>
          <exclude>com.idfconnect.ssorest:common-tools:tests</exclude>
          <exclude>commons-logging:commons-logging</exclude>
          <exclude>junit:junit</exclude>
         </excludes>
        </artifactSet>
       </configuration>
      </execution>
     </executions>
    </plugin>
    <!-- END SHADE -->

   </plugins>
  </build>
</project>


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" <[hidden email]>
To: "Maven Users List" <[hidden email]>
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
>[  [hidden email]  ]
>
>NOTICE: my e-mail address has changed. Please remove
>[hidden email] now and start using [hidden email] from
>now on. Please update your address book. Thank you!
>
>-----Original Message-----
>From: Benson Margulies [mailto:[hidden email]]
>Sent: Monday, September 4, 2017 12:51
>To: Maven Users List <[hidden email]>
>Subject: Re: Where does shaded JAR get its POM?
>
>On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <[hidden email]>
>wrote:
>>On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]>
>>wrote:
>>
>>>AFAIK, as soon as you use a <classifier> 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 <classifier>shaded</classifier>.
>>>
>>
>>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
>>><[hidden email]>
>>>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
>>> > [  [hidden email]<mailto:[hidden email]>  ]
>>> >
>>> >
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���âW6W'2�V�7V'67&�&T�fV��6�R��&pФf�"FF�F����6����G2�R���âW6W'2ֆV��fV��6�R��&p


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Where does shaded JAR get its POM?

Robert Scholte-6
In reply to this post by Sander Verhagen
On Mon, 04 Sep 2017 22:31:41 +0200, Sander Verhagen  
<[hidden email]> 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
> [  [hidden email]  ]
>
> NOTICE: my e-mail address has changed. Please remove [hidden email]  
> now and start using [hidden email] from now on. Please update  
> your address book. Thank you!
>
> -----Original Message-----
> From: Benson Margulies [mailto:[hidden email]]
> Sent: Monday, September 4, 2017 12:51
> To: Maven Users List <[hidden email]>
> Subject: Re: Where does shaded JAR get its POM?
>
> On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <[hidden email]> wrote:
>> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]>  
>> wrote:
>>
>>> AFAIK, as soon as you use a <classifier> 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 <classifier>shaded</classifier>.
>>>
>>
>> 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
>>> <[hidden email]>
>>> 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
>>> > [  [hidden email]<mailto:[hidden email]>  ]
>>> >
>>> >
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Where does shaded JAR get its POM?

Sander Verhagen
In reply to this post by Richard Sand
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
[hidden email]  ]

NOTICE: my e-mail address has changed. Please remove [hidden email] now and start using [hidden email] from now on. Please update your address book. Thank you!

-----Original Message-----
From: Richard Sand [mailto:[hidden email]]
Sent: Monday, September 4, 2017 13:45
To: Maven Users List <[hidden email]>
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!

<project xmlns="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">
  <modelVersion>4.0.0</modelVersion>
  <artifactId>ssorest-plugin-filter-full</artifactId>
  <name>SSO/Rest Servlet Filter Pluigin - Full Package</name>

  <parent>
   <groupId>com.idfconnect.ssorest.plugin</groupId>
   <artifactId>ssorest-plugin-filter-parent</artifactId>
   <version>1.6.4</version>
  </parent>

  <dependencies>
   <!-- Pull in the module-base -->
   <dependency>
    <groupId>com.idfconnect.ssorest.plugin</groupId>
    <artifactId>ssorest-plugin-filter-base</artifactId>
   </dependency>

  <build>
   <plugins>
    <!-- Maven Clean Plugin to remove old DRP files -->
    <plugin>
     <artifactId>maven-clean-plugin</artifactId>
     <version>3.0.0</version>
     <configuration>
      <filesets>
       <fileset>
        <directory>${basedir}</directory>
        <includes>
         <include>*-pom.xml</include>
        </includes>
       </fileset>
      </filesets>
     </configuration>
    </plugin>

    <!-- BEGIN SHADE -->
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-shade-plugin</artifactId>
     <configuration>
      <createDependencyReducedPom>true</createDependencyReducedPom>
     
<keepDependenciesWithProvidedScope>false</keepDependenciesWithProvidedScope>
      <minimizeJar>false</minimizeJar>
      <shadedArtifactAttached>false</shadedArtifactAttached>
      <useBaseVersion>false</useBaseVersion>
      <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
     
<dependencyReducedPomLocation>${output.name}-full-${project.version}-pom.xml</dependencyReducedPomLocation>

      <transformers>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
/>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ApacheLicenseResourceTransformer"
/>
       <transformer
implementation="org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformer">
        <addHeader>false</addHeader>
       </transformer>
      </transformers>
      <filters>
       <filter>
        <artifact>*:*</artifact>
        <excludes>
         <exclude>META-INF/maven/**</exclude>
        </excludes>
       </filter>
      </filters>
      <relocations>
       <relocation>
        <pattern>com.google</pattern>
       
<shadedPattern>com.idfconnect.relocated.com.google</shadedPattern>
       </relocation>
       <relocation>
        <pattern>org.apache.commons</pattern>
       
<shadedPattern>com.idfconnect.relocated.org.apache.commons</shadedPattern>
        <excludes>
         <exclude>org.apache.commons.logging.*</exclude>
        </excludes>
       </relocation>
      </relocations>
     </configuration>

     <!-- EXECUTIONS -->
     <executions>
      <execution>
       <id>full-clear</id>
       <phase>package</phase>
       <goals>
        <goal>shade</goal>
       </goals>
       <configuration>
        <artifactSet>
         <excludes>
          <exclude>com.idfconnect.ssorest:common-tools:tests</exclude>
          <exclude>commons-logging:commons-logging</exclude>
          <exclude>junit:junit</exclude>
         </excludes>
        </artifactSet>
       </configuration>
      </execution>
     </executions>
    </plugin>
    <!-- END SHADE -->

   </plugins>
  </build>
</project>


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" <[hidden email]>
To: "Maven Users List" <[hidden email]>
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
>[  [hidden email]  ]
>
>NOTICE: my e-mail address has changed. Please remove
>[hidden email] now and start using [hidden email] from
>now on. Please update your address book. Thank you!
>
>-----Original Message-----
>From: Benson Margulies [mailto:[hidden email]]
>Sent: Monday, September 4, 2017 12:51
>To: Maven Users List <[hidden email]>
>Subject: Re: Where does shaded JAR get its POM?
>
>On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <[hidden email]>
>wrote:
>>On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <[hidden email]>
>>wrote:
>>
>>>AFAIK, as soon as you use a <classifier> 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 <classifier>shaded</classifier>.
>>>
>>
>>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
>>><[hidden email]>
>>>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.1
>>> > 6 .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
>>> > [  [hidden email]<mailto:[hidden email]>  ]
>>> >
>>> >
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>Т                                                                     Х
>F  V 7V'67& &R R   â
>W6W'2 V 7V'67& &T fV  6 R  &pФf "FF F    6    G2 R   â
>W6W'2ֆV  fV  6 R  &p


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]