`sbt.PluginData#dependencyClasspath` contains multiple `scala-library/compiler/reflect/xml` jars about sbt HOT 6 OPEN

Note that eventually we'll have a Scala 2.12.20 with the scala-xml 2.3.0 upgrade; I just submitted scala/scala#10782.

IMO, it should work for zinc to have a newer scala-xml dependency than scala-compiler does, so it seems to me that something unusual went wrong here. Do we understand what happened, why the dependency was duplicated rather than the older version being evicted?

from sbt.

To avoid classloading scala-library and scala-compiler, sbt launcher creates directories for:

• boot Scala version (the Scala version used by metabuild)
• boot JARs (the rest of sbt main JARs)

and uses a layered classloader at runtime of sbt.

So pluginData#dependencyClasspath I'm guessing is more of an approximation of that situation that we use for the compilation of plugins.

I guess what we should consider is dropping scala-xml from Zinc as a direct dependency so we'd always use whatever Scala 2.x uses at least during Zinc 1.x?

from sbt.

I guess what we should consider is dropping scala-xml from Zinc as a direct dependency

Yeah, I was thinking of suggesting that. I can't think of a downside, but that could be my lack of imagination and/or knowledge. Zinc is cross-published for other versions besides 2.12, I think? Could something go wrong on 2.13 or 3?

from sbt.

Zinc is cross published to Scala 2.13 for 1.x branch.

I guess the complication is that there are modules in sbt like library management that use scala-xml but doesn't depend on the compiler or Zinc, so the diamond dependency issue would remain even if we work around this one.

The other direction of the workaround might be to deduplicate when calculating the plugin classpath so only one of the duplicates are returned to the user.

from sbt.

So pluginData#dependencyClasspath I'm guessing is more of an approximation of that situation that we use for the compilation of plugins.

@eed3si9n Maybe have any suggestions for a better value which we could use to represent a meta-build in IntelliJ?

from sbt.

Somehow related: Define SBT API / Better modularisation for SBT internals

from sbt.