sbt 1.0.4 puts the -sources.jar and -docs.jar in the compile config in ivy.xml

[sjrd]

steps

Using the following build.sbt:

inThisBuild(Def.settings(
  organization := "com.example",
  scalaVersion := "2.11.12"
))

lazy val compplugin = project.
  settings(
  )

$ echo sbt.version=0.13.16 > project/build.properties
$ sbt compplugin/clean compplugin/publishLocal
[...]
$ cp ~/.ivy2/local/com.example/compplugin_2.11/0.1-SNAPSHOT/ivys/ivy.xml ivy-from-sbt013.xml
$ echo sbt.version=1.0.4 > project/build.properties
$ sbt compplugin/clean compplugin/publishLocal
[...]
$ cp ~/.ivy2/local/com.example/compplugin_2.11/0.1-SNAPSHOT/ivys/ivy.xml ivy-from-sbt104.xml
$ diff -u ivy-from-sbt013.xml ivy-from-sbt104.xml > ivy.xml.diff

Results in this gist: https://gist.github.com/sjrd/39b487f3f1f3abb4a5910f583e6d0e9a

problem

The ivy.xml published by sbt 1.0.4 declares the src and doc artifacts in the compile conf, instead of sources/docs as it should.

Concretely, this means that when one depends on such a project, the -sources.jar and -docs.jar are downloaded and added to the compile-time and run-time classpaths!

In the particular case of a scalac compiler plugin, since the -sources.jar also contains the scalac-plugin.xml identifying the jar as a compiler plugin, depending on it with % "plugin" causes two -Xplugin: options to be passed to scalac: one for foo.jar and one for foo-sources.jar. Depending on which one comes first (which I have experienced is non-deterministic), scalac will succeed or fail to load the plugin.

expectation

I expect the same behavior as sbt 0.13, which is also documented as an example of the Ivy documentation for <artifact>: the src artifact should have conf="sources" and the doc artifact should have conf="docs".

notes

In addition to the really serious issue above, sbt 1.0.4 also exposes private configurations used by sbt in the ivy.xml, such as compile-internal.

sbt version: 1.0.4

[sjrd]

This is a blocker for us to migrate the build of Scala.js to sbt 1. Currently our CI fails because of this issue, as can be seen in the PR scala-js/scala-js#3200.

[eed3si9n]

source and docs going into compile is an intentional behavior introduced in 2013 by @dansanduleac as #1016 into 0.14 branch, but was never released, and then became sbt/librarymanagement#25.

If this is causing interference with compiler plugin detection, that might be the buggy code.

[sjrd]

IIRC, the compiler plugin issue happened when

• I published the compiler plugin with sbt 1.0.4, under ^^0.13.16
• then used the compiler plugin from a project using sbt 0.13.16

I think there was no issue when using the compiler plugin from a project using sbt 1.x itself.

So if the changes in sbt/librarymanagement#25 were indeed correct, it seems that something needs to be fixed in 0.13.x for it to be able to correctly resolve artifacts published by sbt 1.x.

[dwijnand]

Fixed in (upcoming - currently RC1) 0.13.17, with #3855 merged.