So doesn’t this require a new directive such as ‘<compile transitive=false”>
scope or similar regardless of safe/rally points? And to provide backwards
compatibility, there must be a split between the legacy consumer view of the
pom and the new producer view of the pom?
> On Nov 5, 2017, at 11:30 PM, Stephen Connolly
> <[email protected]> wrote:
>
>> In the first case, the module creating a shaded jar can mark its
>> constituent jars as optional; preventing the transitive dependencies.
>
>
> Ha! That does not do what you think it does.
>
> Optional dependencies are still there but only as a version constraint that
> gets applied if something else brings the dependency into the tree in as a
> non-optional dependency.
>
> Normally you need a complex deep tree to see the effect (as most people use
> version hints rather than specifications... and with hints, closest wins,
> whereas specifications are globally merged)
>
> Provided scope is more correct, but shade doesn’t operate on provided
> scope... and anyway iirc that also pushes the constraint as transitive.
>
> With shade, the dependency is removed.
