Mill Build Tool，如何使用“驱逐”答案

【问题标题】：Mill Build Tool, how to use `evicted`Mill Build Tool，如何使用“驱逐”
【发布时间】：2020-01-25 16:25:42
【问题描述】：

我想在我的 Mill-项目中运行 evicted。

使用 SBT 可以在sbt-console 中完成，使用：

sbt>evicted

这会返回一个版本冲突警告列表：

[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)
....

Mill 是如何做到的？

我尝试了mill-console，没有命令 (mill resolve _)，而且 Google 也帮不上忙。

【问题讨论】：

我认为是mill resolve __ 为您提供了命令列表（双下划线）。如果它没有列出被驱逐的人（或类似的东西），我猜它是不受支持的
您对evicted 命令有什么期望？你想达到什么目标？
@TobiasRoeser 我添加了 sbt 给你的驱逐结果。
要运行控制台，您需要在具体的 scala 模块上运行控制台：mill -i myModule.console。另请参阅mill inspect myModule.console 的输出。

标签： scala sbt mill

【解决方案1】：

我假设，您正在寻找可能的类路径问题/警告，这是由传递依赖项引入的相同依赖项的不同版本导致的结果。

在mill 中，您可以使用ivyDepsTree 目标来显示具有所有传递常春藤依赖关系的树。此树还包括有关版本调整的详细信息。这些线条将以不同的颜色打印。默认情况下，橙色表示微/补丁版本更改，红色表示次要版本更改。

让我们看一下随机Java项目的以下摘录：

$ 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
...

由于版本冲突，您可以看到一些改编：org.slf4j:slf4j-api:1.7.5 -> 1.7.25（微版本升级）和org.testng:testng:6.11 -> 6.14.2 (possible incompatibility)（小版本升级）。

此外，您可以将输出通过管道传输到 grep 以过滤输出，例如mill __.ivyDepsTree | grep "incompatibility".

这看起来像是一个可用的磨坊，相当于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)

【讨论】：

这并不完全，因为（1）它过滤掉了中间输出行，更重要的是（2）它没有解释它被驱逐的原因。 sbt evicted 告诉您哪些依赖项取决于被驱逐库的哪个版本，因此您可以弄清楚如何修复它。在上面的例子中，什么需要 testng 6.11，什么需要 6.14.2？（我需要能够通过更改取决于另一个的内容来选择我想要的。）
在我的第一个清单（没有 grep 的树）中，您可以清楚地看到，testng:6.11 是mill-contrib.testng 的传递依赖项，将更改为版本6.14.2。那是因为我们也直接依赖于testng:6.14.2。它选择更高的版本。只需遵循代表依赖树的 ascii-art 行即可。
但我怎么知道不是相反，项目依赖于 6.11，而 contrib 库依赖于 6.14，或者可能有其他一些库需要 6.11。跨度>
不知道，我怎么知道我应该坚持使用 6.11 还是 6.14？
因为您总是看到您所依赖的确切版本，并且只有当快递员要偏离时，它才会打印一个额外的箭头（->），然后是最终选择的版本。不过，在该自动选择之上，您可能希望访问依赖项更改日志并做出更详细的选择。