I think both options don't fit very well in the current architecture of Maven.
However, Stephen wrote something related to this for Maven 5.
The idea is to have a metadatafile (pom-like) file for every artifact.
This way you can finally control the actual dependencies for every artifact (including test artifacts)
And I don't think this is very easy to implements.
Both maven-install-plugin and maven-deploy-plugin use the MavenProject as base for all artifacts to install.
All attached artifacts will use exactly the same GAV.
I don't want to have this "temporary" solution in our maven-shade-plugin, because it will be way too difficult to remove it in the future.
Instead I would like to see more people jumping in to work on the true solutions in Maven 5.
And the other solution is of course to write it with your own plugin.
On 8-6-2020 15:40:28, Romain Manni-Bucau <[hidden email]> wrote:
Wonder if there is any issue making shade plugin attaching a virtual
Let me explain myself, i have module foo:bar:1.2.3 and in this module I do
a shade "fat".
Today I can create a classifier=fat and this way I keep bar and bar-fat
Issues with this pattern is both are sharing the same pom so I wonder if we
shouldn't enable maven-shade-plugin to create a virtual artifact, i.e.
1. another artifactId instead of just a classifier (optional since 2 can
handle dependencies properly and be of type=pom, works too),
2. configure a bit more the shaded pom and attach it with the virtual
artifact (enabling to depend on the shade without conflict with the not
Indeed it can be done creating a new module with a dedicated pom but we
start to get patterns where you just want to bulk update the source pom to
something else (in openwebbeans for ex, we have the need to "add jakarta
classifier to all openwebbeans dependencies" or "replace specJavax by
I don't see the point of creating a module just to define this shade, it is
highly overkill and increases the maintenance cost without any gain IMHO so
I'd like to enrich our shade plugin to support a better pom rewriting and
@rmannibucau | Blog
| Old Blog
| Github |
LinkedIn | Book