Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in the mediation of transitive dependencies #40

Open
e-g-hategan opened this issue May 30, 2019 · 7 comments
Open

Bug in the mediation of transitive dependencies #40

e-g-hategan opened this issue May 30, 2019 · 7 comments

Comments

@e-g-hategan
Copy link

Running version v4.2.183.4139.1 (as reported by IntelliJ Idea) of this plugin

THERE SEEMS TO BE A PROBLEM (AS I UNDERSTAND IT) WITH THE TRANSITIVE DEPENDENCIES LIST/TREE WHEN COMPARED TO THE SPECIFICATION

Dependency mediation - this determines what version of an artifact will be chosen when multiple versions are encountered as dependencies. Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.
"nearest definition" means that the version used will be the closest one to your project in the tree of dependencies. For example, if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0.

EXAMPLE

I have the following maven projects (actual names obfuscated):

A 12.0.1
A 13.0.0
A 13.2.0
B 12.0.1
  -> A 12.0.1
B 12.0.2
  -> A 13.0.0
C 8.2.0
  -> A 13.2.0
  -> B 12.0.2
D 0.7.1
  -> A 13.0.0
  -> C 12.0.1

When E is defined as

E 0.9.3
  -> A 13.2.0
  -> C 8.2.0
  -> D 0.7.1

transitive dependencies in the dependency tree/list is wrong

E 0.9.3
  -> A 13.2.0
  -> C 8.2.0
     -> A 13.2.0
     -> B 12.0.2
          -> A 13.0.0 (omitted for conflict with 13.2.0) -- CORRECT
  -> D 0.7.1
    -> A 13.2.0 -- WRONG!!! SHOULD BE 13.0.0 and omitted for conflict with 13.2.0
    -> B 12.0.1 (omitted for conflict with 12.0.2)  -- CORRECT

When E is defined as

E 0.9.3
  -> A 13.2.0
  -> D 0.7.1
  -> C 8.2.0

transitive dependencies in the dependency tree/list is correct

E 0.9.3
  -> A 13.2.0
  -> D 0.7.1
    -> A 13.0.0 (omitted for conflict with 13.2.0) -- CORRECT
    -> B 12.0.1 -- CORRECT 
          -> A 12.0.1 (omitted for conflict with 13.2.0) -- CORRECT
  -> C 8.2.0
     -> A 13.2.0
     -> B 12.0.2 (omitted for conflict with 12.0.1) -- CORRECT

Why this bothers me is that it failed to report a dependency conflict when it was supposed to!

@e-g-hategan e-g-hategan changed the title Bug in the conflict identification algorithm Bug in the mediation of transitive dependencies May 30, 2019
@krasa
Copy link
Owner

krasa commented May 30, 2019

Could you check if IntelliJ diagram in Ultimate version works the same? Or at least if the dependency in the Project Settings or Maven tool window is also wrong.

The plugins does not resolve dependencies, only determines conflicts, so if the dependency is wrong, then it is likely a fault of IntelliJ-Maven integration (it would not be for the first time).

@krasa
Copy link
Owner

krasa commented Jun 4, 2019

@e-g-hategan
Copy link
Author

Thank you for raising the relevant ticket with jetbrains @krasa.

Feel free to close the issue since not relevant for maven helper project.

@krasa
Copy link
Owner

krasa commented Jun 6, 2019

Well, it really is relevant :)
Perhaps I will find a workaround.

krasa added a commit that referenced this issue Jun 6, 2019
@krasa
Copy link
Owner

krasa commented Jun 6, 2019

I released a new version with a fix.

@ruwanka
Copy link

ruwanka commented Jul 15, 2020

Hi @krasa, still I am getting this conflict message on version (4.9.193.000.0). Any idea?

@krasa
Copy link
Owner

krasa commented Aug 6, 2020

@ruwanka probably a bug, I might have done it too strict. A reproducible project would help, or you could debug it yourself

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants