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 <users@maven.apache.org>
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" <san...@sanderverhagen.net>
To: "Maven Users List" <users@maven.apache.org>
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 <users@maven.apache.org>
>Subject: Re: Where does shaded JAR get its POM?
>
>On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar <and...@hammar.net>
>wrote:
>>On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer <t.bro...@gmail.com>
>>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 
>>><san...@sanderverhagen.net>
>>>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
>>> > [  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
>
>Т                                                                     Х
>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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to