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 <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> ] > >
