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