regression: some repos now fail with cross-version suffixes error on scala-xml

[SethTisue]

Conflicting cross-version suffixes in: org.scala-lang.modules:scala-xml

not sure when this started or what's going on, need to investigate. some of the failing repos are kind-projector, scalajson, akka-actor

[SethTisue]

in scalajson's case I think this might have to do with the scalajson -> scalatest -> scalactic -> scala-reflect -> scala-xml dependency chain?

oh but that isn't the chain, scala-reflect doesn't depend on scala-xml. the scala-xml dependency is scalatest's.

[SethTisue]

not sure I have a complete list of failing projects in hand, but:

I think all the failing projects are either:

• compiler plugins (kind-projector, twotails)
• ScalaTest users (the others)

[SethTisue]

from e.g. the kind-projector log,

[kind-projector] [info] 	org.scala-lang.modules#scala-xml;0.1-dbuildxa3d7c1f2fbbff31cd9ef52c50629720657fe755c from mvn-build-local in [compile, runtime, test, provided, compile-internal, runtime-internal, test-internal, scala-tool]
[kind-projector] [info] 	org.scala-lang.modules#scala-xml_2.12;1.0.6 from cache in [compile, runtime, test, provided, compile-internal, runtime-internal, test-internal]

note the missing _2.12

[SethTisue]

I wonder exactly this when regressed, there might be a clue there. but Jenkins is down

downgrading sbt-version from 0.13.17 to 0.13.16 doesn't help. running dbuild with version=2.12.4 doesn't help.

oh, now this is interesting: scala/scala-xml#181

that looks very interesting

/cc @ashawley

[SethTisue]

darnit, rewinding scala-xml to scala/scala-xml@171a199 (October 2017) doesn't make the errors go away. sorry Aaron, false alarm

[ashawley]

Yeah, I wondered what fixing the exclusion rule would actually do to do the community build, but then the Typesafe Jenkins crashed, so I never found out, until...

Ok, hope it is a false alarm.

[SethTisue]

okay, I noticed something else the failing projects have in common: they are on sbt 1.

and yeah, if I rewind kind-projector to typelevel/kind-projector@5729d05, before the sbt 1 move, the problem goes away.

so that's progress at least, this is some sbt 0.13 vs sbt 1 difference

[SethTisue]

using kind-projector as our guinea pig, on sbt 0.13.17 ++2.12.4 then show fullClasspath shows:

[info] * Attributed(/Users/tisue/.ivy2/cache/org.scala-lang/scala-compiler/jars/scala-compiler-2.12.4.jar)
[info] * Attributed(/Users/tisue/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.12.4.jar)
[info] * Attributed(/Users/tisue/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.12.4.jar)
[info] * Attributed(/Users/tisue/.ivy2/cache/org.scala-lang.modules/scala-xml_2.12/bundles/scala-xml_2.12-1.0.6.jar)

but on sbt 1.1.0

[info] * Attributed(/Users/tisue/.sbt/boot/scala-2.12.4/lib/scala-compiler.jar)
[info] * Attributed(/Users/tisue/.sbt/boot/scala-2.12.4/lib/scala-library.jar)
[info] * Attributed(/Users/tisue/.sbt/boot/scala-2.12.4/lib/scala-reflect.jar)
[info] * Attributed(/Users/tisue/.ivy2/cache/org.scala-lang.modules/scala-xml_2.12/bundles/scala-xml_2.12-1.0.6.jar)

is the difference significant? not sure. it sure looks relevant. also fwiw ~/.sbt/boot/scala-2.12.4/lib contains a scala-xml_2.12.jar

[SethTisue]

Scalatest's xml dependency, from its ivy-3.0.4.xml:

        <dependency org="org.scala-lang.modules" name="scala-xml_2.12" rev="1.0.5" force="true" conf="compile->compile(*),master(compile);runtime->runtime(*)"/>

[SethTisue]

I wonder if this is a bug in dbuild's "Scala" build system. org.scala-lang.modules#scala-xml;0.1-dbuildxa3d7c1f2fbbff31cd9ef52c50629720657fe755c is just wrong (missing _2.12), and it's got dbuild's fingerprints on it.

hypothesis: scala-compiler, scala-library, and scala-reflect all correctly lack the _2.12 suffix, so maybe dbuild thinks everything that's part of the Scala bootstrap is supposed to lack a binary version suffix.

that would still leave me confused about the sbt 0.13 vs sbt 1 part, though...

[SethTisue]

okay I bet we can deal with this by pulling scala-xml out of the "Scala" build system section, or maybe by not using that build system at all. which would be a nice simplification anyway actually

trying it...

[SethTisue]

thinking out loud:

• in a 2.12 context, we could say that's it, we're just not upgrading the scala-xml version used by Scaladoc anymore. so then there's no need to have scala-xml in the 2.12 community build (except perhaps as a standalone thing that isn't used by any downstream projects)
• in a 2.13 context, we plan to cut the Scaladoc tools's dependency on scala-xml anyway, so at that point scala-xml becomes just another project.