On Mon, 04 Sep 2017 22:31:41 +0200, Sander Verhagen
<san...@sanderverhagen.net> 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
[ 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
