For at least one 2.11 project, instrumented with the sbt plugin, sbt fails to start, with what appears to be a scala macros version collision. See http://stackoverflow.com/questions/38956534/scala-package-contains-object-and-package-with-same-name for the error message.
Has it never worked for projects using macros? I find that unlikely, but need to check again.
The scala macros library structure has changed considerably between 2.11 and 2.10, but that alone does not directly imply that the classpath gets polluted with two different versions of scala.reflect.macros when sbt merely loads the project.
The project for which this happens (proprietary code) has a lot of other sbt plugins used by it:
addSbtPlugin("com.typesafe.sbt" % "sbt-web" % "1.3.0") // "latest.release"
addSbtPlugin("com.typesafe.sbt" % "sbt-twirl" % "1.1.1")
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "4.0.0")
addSbtPlugin("io.spray" % "sbt-revolver" % "0.8.0")
libraryDependencies += "mysql" % "mysql-connector-java" % "5.1.38"
addSbtPlugin("org.scalikejdbc" %% "scalikejdbc-mapper-generator" % "2.4.2")
addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.3")
For at least one 2.11 project, instrumented with the sbt plugin, sbt fails to start, with what appears to be a scala macros version collision. See http://stackoverflow.com/questions/38956534/scala-package-contains-object-and-package-with-same-name for the error message.
Has it never worked for projects using macros? I find that unlikely, but need to check again.
The scala macros library structure has changed considerably between 2.11 and 2.10, but that alone does not directly imply that the classpath gets polluted with two different versions of scala.reflect.macros when sbt merely loads the project.
The project for which this happens (proprietary code) has a lot of other sbt plugins used by it: