Description
Bryan Beaudreault opened MSHADE-465 and commented
In order for a shaded jar to be a drop-in replacement, promoteTransitiveDependencies should be true. This has an annoying side-effect of flattening the dependency tree. For example, suppose you have a project named MyShadeModule with the following dependency tree:
MyShadeModule
-> Module A
-> Module B
-> Module D
-> Module E
-> Module C
Let's say you include Module A in the shaded jar. If promoteTransitiveDependencies you'll end up with the following:
MyShadeModule
-> Module B
-> Module D
-> Module E
-> Module C
This is a frustrating result, because let's you have Module B under dependencyManagement in a downstream project. Which version you pin Module B to might dictate which transitive dependencies it would normally include. For example maybe Module B 1.0 depends on D and E, while 2.0 depends only on F. In a normal non-shaded environment, your downstream project would end up depending on modules B, F, and C. But if you depend on a shaded artifact, you end up with modules B, D, E, F, C.
It would be preferable to limit the max depth of transitive promotion, so that you can end up with the more accurate:
MyShadeModule
-> Module B
-> Module C
If you import that module into a downstream project, maven will resolve the transitive dependencies for Module B. This way you can take into account any dependencyManagement in the downstream project.
I realize this may not be the desired behavior for everyone, so it might be good to be a new config option.
No further details from MSHADE-465