Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dbuild breaks scalaBinaryVersion #145

Closed
gkossakowski opened this issue Oct 17, 2014 · 2 comments
Closed

Dbuild breaks scalaBinaryVersion #145

gkossakowski opened this issue Oct 17, 2014 · 2 comments
Labels

Comments

@gkossakowski
Copy link

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
Copy link
Author

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.

gkossakowski added a commit to gkossakowski/twirl that referenced this issue Oct 17, 2014
Dbuild manipulates scalaBinaryVersion which breaks twirl's matching when
selecting specs2 dependency. See lightbend-labs/dbuild#145 for details.
gkossakowski added a commit to gkossakowski/twirl that referenced this issue Oct 17, 2014
Dbuild manipulates scalaBinaryVersion which breaks twirl's matching when
selecting specs2 dependency. See lightbend-labs/dbuild#145 for details.
gkossakowski added a commit to gkossakowski/twirl that referenced this issue Oct 20, 2014
This is another workaround for lightbend-labs/dbuild#145. This time we deal
with the problem of Scala version-dependent inclusion of source files to
be compiled. Selection of a source folder is broken because it is based
on scalaBinaryVersion which dbuild overrides. The workaround is to
fallback to "2.11" value for scalaBinaryVersion when the one set in the
build is not included in the known set ("2.9.3, "2.10", "2.11").
@cunei
Copy link

cunei commented Oct 20, 2014

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 sbt/sbt#1573 for some additional information.
I am closing this issue, but please feel free to reopen if you would like to add further comments.

@cunei cunei closed this as completed Oct 20, 2014
gkossakowski added a commit to gkossakowski/twirl that referenced this issue Oct 21, 2014
This is another workaround for lightbend-labs/dbuild#145. This time we deal
with the problem of Scala version-dependent inclusion of source files to
be compiled. Selection of a source folder is broken because it is based
on scalaBinaryVersion which dbuild overrides. The workaround is to
fallback to "2.11" value for scalaBinaryVersion when the one set in the
build is not included in the known set ("2.9.3, "2.10", "2.11").
gkossakowski added a commit to gkossakowski/community-builds that referenced this issue Oct 21, 2014
Latest version of Play depends on a new twirl that has been moved to
Play organization on GitHub. That version doesn't build in dbuild due to
pattern matching on scalaBinaryVersion, see playframework/twirl#45 and
lightbend-labs/dbuild#145 for details. For that reason, we are building Play's
Twirl from a head of PR which includes workaround for scalaBinaryVersion
problem.

However, we can't switch over to Play's Twirl altogether just yet. The
reason is that spray fork depends on old twirl.

The good news is that Spray's and Play's Twirl do not share group ids so
we can just build both of them and they'll be picked up by projects that
need them. That's what we are doing here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants