3

I want to run evicted in my Mill-project.

With SBT it can be done in the sbt-console, using:

sbt>evicted

This returns a list of version conflicts warnings:

[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn]  * com.typesafe:ssl-config-core_2.13:0.3.8 is selected over 0.4.0
[warn]      +- com.typesafe.play:play-ws-standalone_2.13:2.0.6    (depends on 0.3.8)
[warn]      +- com.typesafe.play:play_2.13:2.7.3 ()               (depends on 0.3.8)
[warn]      +- com.typesafe.akka:akka-stream_2.13:2.5.23 ()       (depends on 0.4.0)
....

How is this done with Mill?

I tried the mill-console, there is no command (mill resolve _) and also Google could not help.

pme
  • 14,156
  • 3
  • 52
  • 95
  • I think it's `mill resolve __` that gives you a list of commands (double underscore). If it doesn't list the evicted (or something similar) than I guess it's not supported – J0HN Sep 25 '19 at 13:23
  • What do you expect from an `evicted` command? What do you want to achieve? – Tobias Roeser Sep 25 '19 at 14:44
  • @TobiasRoeser I added the result sbt gives you for evicted. – pme Sep 25 '19 at 14:51
  • To run a console, you need to run the console on a concrete scala module: `mill -i myModule.console`. See also the output of `mill inspect myModule.console`. – Tobias Roeser Sep 25 '19 at 21:38

1 Answers1

4

I assume, you are looking for possible classpath issues/warnings, which are the result of different versions of the same dependencies pulled in by transitive dependencies.

In mill, you can use the ivyDepsTree target to display a tree with all transitive ivy dependencies. This tree also includes details about version adjustments. Those lines will be printed in different colors. By default, orange for micro/patch version changes, red for minor version changes.

Let's look at the following excerpt from a random Java project:

$ mill __.ivyDepsTree
...
[416/426] <redacted>.test.ivyDepsTree
├─ com.lihaoyi:mill-contrib-testng:0.5.1-14-ef3708
│  ├─ org.scala-sbt:test-interface:1.0
│  └─ org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)
│     ├─ com.beust:jcommander:1.72
│     └─ org.apache-extras.beanshell:bsh:2.0b6
├─ org.testng:testng:6.14.2
│  ├─ com.beust:jcommander:1.72
│  └─ org.apache-extras.beanshell:bsh:2.0b6
├─ de.tototec:de.tobiasroeser.lambdatest:0.7.0
├─ org.slf4j:slf4j-api:1.7.25
├─ ch.qos.logback:logback-classic:1.2.3
│  ├─ ch.qos.logback:logback-core:1.2.3
│  └─ org.slf4j:slf4j-api:1.7.25
├─ org.aspectj:aspectjrt:1.8.13
├─ org.fedorahosted.tennera:jgettext:0.15
│  ├─ antlr:antlr:2.7.7
│  └─ org.slf4j:slf4j-api:1.7.5 -> 1.7.25
├─ org.antlr:com.springsource.antlr:2.7.7
...

You can see some adaptions because of conflicting versions: org.slf4j:slf4j-api:1.7.5 -> 1.7.25 (micro version upgrade) and org.testng:testng:6.11 -> 6.14.2 (possible incompatibility) (minor version upgrade).

Further, you could pipe the output to grep to filter the output, e.g. mill __.ivyDepsTree | grep "incompatibility".

And this looks like a usable mill equivalent to sbt evicted.

$ mill __.ivyDepsTree | grep "incompatibility"
...
[416/426] <redacted>.test.ivyDepsTree 
│  └─ org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)
│  ├─ org.hibernate:com.springsource.org.hibernate:3.2.6.ga -> 3.3.2.GA (possible incompatibility)
│  ├─ org.jboss.javassist:com.springsource.javassist:3.3.0.ga -> 3.9.0.GA (possible incompatibility)
│  └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│  │     └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│  │  │     └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│  │  │  └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│  │  └─ org.testng:testng:6.4 -> 6.14.2 (possible incompatibility)
│  └─ org.testng:testng:6.4 -> 6.14.2 (possible incompatibility)
│     │     └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
│        └─ org.objenesis:objenesis:1.2 -> 2.6 (possible incompatibility)
Tobias Roeser
  • 431
  • 2
  • 8
  • It's not totally, because (1) it filters out intermediate output lines, and more importantly (2) it doesn't explain why it was evicted. `sbt evicted` tells you which dependencies depend on which version of the evicted library, so you can figure out how to fix it. In the above example what wants testng 6.11 and what wants 6.14.2? (I need to be able to choose which one I want by changing whatever depends on the other one.) – nafg Nov 29 '21 at 03:46
  • In my first listing (the tree without grep), you can clearly see, that `testng:6.11` is a transitive dependency of `mill-contrib.testng` and will be changed to version `6.14.2`. That is because we also depend directly on `testng:6.14.2`. It chooses the higher version. Just follow the ascii-art lines which represent a dependency tree. – Tobias Roeser Nov 30 '21 at 08:43
  • But how do I know it wasn't the other way around, that the project depends on 6.11 and the contrib library depends on 6.14, or maybe there's some other library or libraries that want 6.11. – nafg Dec 01 '21 at 20:35
  • Without knowing that, how can I know if I should stick with 6.11 or 6.14? – nafg Dec 01 '21 at 20:35
  • Because you always see the exact version your are depending on, and only if coursier is going to deviate, it will print an additional arrow (`->`) followed by the finally selected version. Above that automatic choice, you may want to visit the dependencies changelog and make a more elaborated choice, though. – Tobias Roeser Dec 02 '21 at 09:42
  • To put it in other words: This line ```│ └─ org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)``` means, there is a transitive dependency to `org.testng:testng:6.11` but we choose to use version `6.14.2` instead, which may turn out as an `possible incompatibility`. We decided to select that version, because there are other dependencies selecting this one, e.g. the direct dependency `├─ org.testng:testng:6.14.2` – Tobias Roeser Dec 02 '21 at 09:56
  • What exactly would look different if the situation were reversed, that the build added 6.11 and the library added 6.14, or if it was two libraries rather than the build vs. a library? – nafg Dec 03 '21 at 18:09
  • Maybe you just want to try it out yourself? This small comment box is unsuited to continue this. Or come to Mills chat room or discussion forum. – Tobias Roeser Dec 05 '21 at 20:05