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.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
Т���������������������������������������������������������������������Х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
