search

lightbend-labs / dbuild

Multi-project build tool, based on sbt.
https://lightbend-labs.github.io/dbuild
Other
83 stars 14 forks source link

Dbuild breaks scalaBinaryVersion #145

Closed gkossakowski closed 9 years ago

gkossakowski commented 9 years ago

Dbuild makes it difficult to run builds that rely on matching scalaBinaryVersion:

[play-twirl:error] scala.MatchError: 2.11.3-dbuildx1882bf53040139d9fd00e0c582bd1dcfd5e44573 (of class java.lang.String)
[play-twirl:error]  at $1566a16893598a20b1cb$.specs2(build.sbt:132)
[play-twirl:error]  at $1566a16893598a20b1cb$$anonfun$plugin$9.apply(build.sbt:53)
[play-twirl:error]  at $1566a16893598a20b1cb$$anonfun$plugin$9.apply(build.sbt:53)
[play-twirl:error]  at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:177)
[play-twirl:error]  at sbt.EvaluateSettings$INode.evaluate(INode.scala:135)
[play-twirl:error]  at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:67)
[play-twirl:error]  at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:76)
[play-twirl:error]  at sbt.EvaluateSettings$$anon$3.run(INode.scala:72)

The relevant fragment in twirl build is:

def specs2(scalaBinaryVersion: String) = scalaBinaryVersion match {
  case "2.9.3" => "org.specs2" %% "specs2" % "1.12.4.1" % "test"
  case "2.10" | "2.11" => "org.specs2" %% "specs2" % "2.3.11" % "test"
}
gkossakowski commented 9 years ago

Would it make sense for dbuild to preserve the proper scalaBinaryVersion? In this particular case we would have scalaVersion set to 2.11.3-dbuildx1882bf53040139d9fd00e0c582bd1dcfd5e44573 but scalaBinaryVersion would be still 2.11.3 during resolving dependencies. When building (and publishing) keeping full binary version probably makes sense.

cunei commented 9 years ago

In dbuild, the scalaBinaryVersion is normally set to the same value as scalaVersion; that helps to resolve dependencies exclusively against the artifacts that have been compiled in the same dbuild run, rather than whatever other dependencies may be available in other repositories. I would argue that this is not something that needs to be fixed in dbuild: projects should be able to cope with arbitrary versions of scala, which may lead to a wider range of possible values for scalaBinaryVersion, as you did in your fix to twirl. The computation of scalaBinaryVersion is actually pretty complex, and the previous twirl code would equally fail with some snapshot versions of the scala compiler. You may refer to https://github.com/sbt/sbt/pull/1573 for some additional information. I am closing this issue, but please feel free to reopen if you would like to add further comments.