optional dependency and its relationship to transitive dependencies requireing the same dependency

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

optional dependency and its relationship to transitive dependencies requireing the same dependency

James Nord
Hi all,

I was a bit surprised at something I saw when a project A had an optional
dependency on B and a non optional dependency on C that had a dependency on
B.

I couldn't find any documentation about the expected behaviour but to me
the observed behaviour seems wrong, so either I am wrong and would like
someone to explain to me why, or I need to file a bug.

So dependencies look like

Project A  -> Project B (optional)
                 ->Project C -> Project D
               -> Project E

Which means that the dependencies required for A are C,D and E.  All good.

Now suppose I upgrade the version of E and that new version of E has a non
optional dependency on B.

Project A  -> Project B (optional)
                 ->Project C -> Project D
               -> Project E -> Project B

Here I would expect as my library can no longer function correctly without
B (as code in E would blow up at runtime) that B would end up being non
optional

or to put it another way I would expect the calculated dependencies for A
are C, D E and B

However this is not the case and B is still shown marked as optional (via
dependency:3.1.1:tree in maven 3.5.2 and my home grown aether resolution
logic*).

Now an argument could be made that as optionality was declared at A that it
trumps transitive dependencies, but this is not in dependencyManangement -
hence the surprise.  I would also expect the only way to remove a
transitive dependency that was in scope would be by adding an explicit
exclusion on it at the root of the dependency tree.

So can someone explain this behaviour to me - is it expected, a bug,
something no one has thought about before?

Thanks in advance

/James

* which could easily also be wrong