Questions about reconciled vs retained versions and ranges #2481

ckipp01 · 2022-07-19T15:12:05Z

ckipp01
Jul 19, 2022

This is a bit hard to explain without some examples, but in https://github.com/ckipp01/mill-github-dependency-graph I'm using DependencyTree to get the hierarchy of dependencies that end up being resolved in a Mill build. When starting to work on this I came across the reconciledVersion and the retainedVersion here:

coursier/modules/core/shared/src/main/scala/coursier/graph/DependencyTree.scala

Lines 14 to 17 in 9be5c72

    
             def reconciledVersion: String 
        
             /** The final version of this dependency. */ 
        
             def retainedVersion: String

Due to the comment on retainedVersion I sort of assumed that in a situation where a range version was used, this retainedVersion would actually be the final resolved dependency, but that ended up not being the case. I then switched to using reconciledVersion which seemed to fix the issue, but then I still come across some situations where the reconciledVersion is still a range, and I don't fully understand how that's possible.

For example if we look at org.jongo:jongo:1.5.0 notice that the jackson-core version is a range. However, when using cs resolve you see this is correctly resolved:

❯ cs resolve org.jongo:jongo:1.5.0
com.fasterxml.jackson.core:jackson-annotations:2.12.3:default
com.fasterxml.jackson.core:jackson-core:2.12.3:default
com.fasterxml.jackson.core:jackson-databind:2.12.3:default
de.undercouch:bson4jackson:2.12.0:default
org.jongo:jongo:1.5.0:default

Now we'll piggy back a bit on mill's .ivyDepsTree. If we have a minimal build with jongo like this:

object minimal extends ScalaModule {
  def scalaVersion = "2.13.8"

  def ivyDeps = Agg(
    ivy"org.jongo:jongo:1.5.0"
  )
}

See the following tree:

❯ mill minimal.ivyDepsTree
[9/9] minimal.ivyDepsTree
├─ org.jongo:jongo:1.5.0
│  ├─ com.fasterxml.jackson.core:jackson-annotations:[2.7.0,2.12.3] -> 2.12.3
│  ├─ com.fasterxml.jackson.core:jackson-core:[2.7.0,2.12.3] -> 2.12.3
│  ├─ com.fasterxml.jackson.core:jackson-databind:[2.7.0,2.12.3] -> 2.12.3
│  │  ├─ com.fasterxml.jackson.core:jackson-annotations:2.12.3
│  │  └─ com.fasterxml.jackson.core:jackson-core:2.12.3
│  └─ de.undercouch:bson4jackson:2.12.0
└─ org.scala-lang:scala-library:2.13.8

We see that there was a range, but it's been fully resolved to 2.12.3. This makes sense. However, if we add another dependency on jackson-core specifically, notice that there is still a node in the tree with range:

object minimal extends ScalaModule {
  def scalaVersion = "2.13.8"

  def ivyDeps = Agg(
    ivy"org.jongo:jongo:1.5.0",
    ivy"com.fasterxml.jackson.core:jackson-core:2.13.3"
  )
}

❯ mill minimal.ivyDepsTree
[9/9] minimal.ivyDepsTree
├─ org.jongo:jongo:1.5.0
│  ├─ com.fasterxml.jackson.core:jackson-annotations:[2.7.0,2.12.3] -> 2.12.3
│  ├─ com.fasterxml.jackson.core:jackson-core:[2.7.0,2.12.3]
│  ├─ com.fasterxml.jackson.core:jackson-databind:[2.7.0,2.12.3] -> 2.12.3
│  │  ├─ com.fasterxml.jackson.core:jackson-annotations:2.12.3
│  │  └─ com.fasterxml.jackson.core:jackson-core:2.12.3
│  └─ de.undercouch:bson4jackson:2.12.0
├─ com.fasterxml.jackson.core:jackson-core:2.13.3
└─ org.scala-lang:scala-library:2.13.8

In this situation, why is com.fasterxml.jackson.core:jackson-core:[2.7.0,2.12.3] still in there and why does it not have a -> 2.13.3 since I'm assuming coursier knows that this range will be fully resolved to 2.13.3? Is this a bug, or am I just misunderstanding how this is supposed to work?

ckipp01 · 2022-12-01T11:37:21Z

ckipp01
Dec 1, 2022
Author

@alexarchambault do you by chance have any insight into the above?

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Questions about reconciled vs retained versions and ranges #2481

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Questions about reconciled vs retained versions and ranges #2481

Uh oh!

Uh oh!

ckipp01 Jul 19, 2022

Replies: 1 comment

Uh oh!

ckipp01 Dec 1, 2022 Author

ckipp01
Jul 19, 2022

ckipp01
Dec 1, 2022
Author