Replies: 1 comment
-
@alexarchambault do you by chance have any insight into the above? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 thereconciledVersion
and theretainedVersion
here:coursier/modules/core/shared/src/main/scala/coursier/graph/DependencyTree.scala
Lines 14 to 17 in 9be5c72
Due to the comment on
retainedVersion
I sort of assumed that in a situation where a range version was used, thisretainedVersion
would actually be the final resolved dependency, but that ended up not being the case. I then switched to usingreconciledVersion
which seemed to fix the issue, but then I still come across some situations where thereconciledVersion
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 thejackson-core
version is a range. However, when usingcs resolve
you see this is correctly resolved:Now we'll piggy back a bit on mill's
.ivyDepsTree
. If we have a minimal build with jongo like this:See the following tree:
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: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?Beta Was this translation helpful? Give feedback.
All reactions