Improvement request: Produce shaded artifact with dependency reduced pom

[jwiklund]

Description

Since the shaded jar is specified by a classifier there is no dependency reduced pom.xml available (it shares the main's pom) meaning we still have to resolve the dependency conflicts (by using our own versions) even when using the shaded artifact.

How to reproduce

See the dependencies of the docker-client, they include jackson and glassfish artifacts that are already inside the shaded artifact.

What do you expect

Anther artifact, maybe docker-client-shaded which does not have these dependencies.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vjkoskela]

👍 This is a problem for us as well; we are using the shaded pom to work around a Guava conflict with between our dependencies and those in docker-client. Aside from the Immutable* return types which expose the shaded Guava package-path (already reported in #930), the shaded version resolves the actual class conflict for us.

However, our build system still sees the nested dependencies because the pom published with the shaded jar is the same as the original instead of the dependency reduced pom created by the shade plugin. Would it be possible to upload the shaded jar with its own pom likely as an alternate artifact instead of a different classification?

[vjkoskela]

Let me add some details to my suggestion. Since Maven can only produce a single pom for each module, the solution requires a multi-module project. One sub-module contains the library without shading and a second sub-module depends on the first and performs the shading. No classifier is needed on the second module as it can (and must) have a separate artifact id. You can find an example of this here; please note this project contains additional build rules which are likely not applicable here.