-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
Would it make sense for dbuild to preserve the proper scalaBinaryVersion? In this particular case we would have |
Dbuild manipulates scalaBinaryVersion which breaks twirl's matching when selecting specs2 dependency. See lightbend-labs/dbuild#145 for details.
Dbuild manipulates scalaBinaryVersion which breaks twirl's matching when selecting specs2 dependency. See lightbend-labs/dbuild#145 for details.
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").
In dbuild, the |
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").
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.
Dbuild makes it difficult to run builds that rely on matching
scalaBinaryVersion
:The relevant fragment in twirl build is:
The text was updated successfully, but these errors were encountered: