I am using a JSON extension which relies on Mandubian's play-json 2.2-SNAPSHOT. Everything worked fine until now I have a project based on Scala-STM. sbt reports the following problem:
[error] Modules were resolved with conflicting cross-version suffixes
in {file:folder}project:
[error] org.scala-stm:scala-stm _2.10, _2.10.0
java.lang.RuntimeException: Conflicting cross-version suffixes in:
org.scala-stm:scala-stm
Is there any chance to dig deeper into where these two "conflicting" versions come from? I am quite surprised that play-json should be depending on scala-stm?!
Furthermore, is there a way to convince sbt to shut the ... up. Because obviously 2.10 and 2.10.0 are equivalent versions.
EDIT: This seems to be an sbt 0.13 bug (and probably has nothing to do with Play-JSON), because if I revert to 0.12.4, the project successfully updates and builds. I am still interested in a work around for sbt 0.13.
You can get around this by removing scala-stm with exclude
"dependencyGroupId" %% "dependencyArtifactId" % "dependencyVersion" exclude("org.scala-stm", "scala-stm_2.10.0")
Do not forget to do sbt clean.
Updated Play2 2.2 - downgrading to SBT from 0.13.0 -> 0.12.4 didn't work with me, but excluding using exclude("org.scala-stm", "scala-stm_2.10.0") on ALL app-specific dependencies I had worked fine -- anyway -- none of my dependencies shouldn't have anything to do with scala-stm.
If you'd like to see all libraries being pulled in to your SBT project, you can use the SBT dependency graph plugin.
Using this, you can see why scala-stm is being pulled in, and also check for other conflicting scala 2.10 and 2.11 dependencies.
Related
I tried to use scalameter 0.21 (and some other versions) with scala 3.1.2.
I added some configurations from the scalameter web-page in my build.sbt file and tried serveral things to make this work, but sbt was not able to find the desired packages.
I would have concluded that scalameter is simply not available for scala3, but there is a question here where somebody somehow got it to work.
The problem seemed to bee that sbt added a 3 in all the sources, as in:
https://repo1.maven.org/maven2/com/storm-enroute/scalameter_3/0.21/scalameter_3-0.21.pom
but the path with scalameter_3 did not exist. If I change the scalaversion to 2.13.8, sbt is able to download all the nesessary files without error. Starting with scala version 3.0.0 the problem exists.
If somebody could post a build.sbt file where scalameter and scala3 are used together, I would apreciate it.
Otherwise, if somebody knows a different library for benchmarking with scala 3...
Thanks very much
As #maxkar mentioned, using crossVersion should do the job:
("com.storm-enroute" %% "scalameter" % "0.21").cross(CrossVersion.for3Use2_13) % Test
However, doing so, you may encounter a problem with conflicting dependencies, e.g.:
[error] Modules were resolved with conflicting cross-version suffixes in ProjectRef(...
[error] org.scala-lang.modules:scala-xml _2.13, _3
In such a case, dependency exclusion, as described in sbt documentation, should solve the issue:
("com.storm-enroute" %% "scalameter" % "0.21").cross(CrossVersion.for3Use2_13) % Test exclude("org.scala-lang.modules", "scala-xml_2.13")
I'm not sure if this cannot backfire in certain situations, but it worked perfectly in my case.
I had been using Scalariform in a project I upgraded to Scala 2.11. In doing so, I discovered that Scalariform does not appear to have an artifact published for 2.11 in any of the usual places. This makes the usual sbt cross-version dependency unhappy.
As 2.11 has been out for a while already, this has me questioning if the usage of Scalariform as an embedded library should be considered abandoned? Has the community moved on to an alternative I just don't know about?
Scalafmt is an alternative code formatter that does compile to 2.11 and can be used as an embedded library. An up-to-date usage example is here https://olafurpg.github.io/scalafmt/#Standalonelibrary
I am trying to use scala-pickling in one of my projects. I tried to mimic the build file of macroid which seems to use pickling too but I keep getting this error on sbt test:
[error] Modules were resolved with conflicting cross-version suffixes in dijon:
[error] org.scalamacros:quasiquotes _2.10, _2.10.3
java.lang.RuntimeException: Conflicting cross-version suffixes in: org.scalamacros:quasiquotes
at scala.sys.package$.error(package.scala:27)
at sbt.ConflictWarning$.processCrossVersioned(ConflictWarning.scala:47)
at sbt.ConflictWarning$.apply(ConflictWarning.scala:30)
at sbt.Classpaths$$anonfun$61.apply(Defaults.scala:1044)
at sbt.Classpaths$$anonfun$61.apply(Defaults.scala:1044)
Full build log is here. What am I doing wrong? What should I change in my build.sbt to fix this? I also should be able to cross compile and release my library against both 2.10.x and 2.11.x.
Starting from 2.0.0-M7, org.scalamacros % quasiquotes are cross-versioned as binary (i.e. _2.10) and not as full (i.e. _2.10.x): http://scalamacros.org/news/2014/04/03/macro-paradise-2.0.0-M7.html. Looks like one of your dependencies uses pre-M7 quasiquotes and another one uses post-M7 quasiquotes.
I don't think this can fixed in any way other than upgrading all the dependencies that use the old quasiquote library, because pre-M7 and post-M7 quasiquote libraries are incompatible.
The problem is that you are using two different versions of the quasiquotes module that allows defining Scala macros. You should make sure that only a single version is used, and that this single version is matched by all your dependencies that use macros.
Also, are you sure that scala-pickling was released for Scala 2.11.x? Judging, from their build file, they released only for 2.10.3 - https://github.com/scala/pickling/blob/2.10.x/project/Build.scala#L10.
First, try to remove:
crossScalaVersions := Seq("2.10.4", "2.11.0-RC4")
And try again. After that, set the Scala version to 2.10.3, so that it matches the one in scala-pickling.
scalaVersion := "2.10.3"
EDIT: See Eugene's answer below for a more detailed explanation.
According to my dependencyGraph from pulling in spray-testkit_2.10-1.3.2, specs2_2.10 v1.3.10 is still using a milestone release of quasiquotes. I ran the cross version error issue because of this.
I was getting the unresolved dependencies like the question here.
Getting org.scala-tools.sbt sbt_2.9.1 0.7.7 ...
::::::::::::::::::::::::::::::::::::::::::::::
:: UNRESOLVED DEPENDENCIES ::
::::::::::::::::::::::::::::::::::::::::::::::
:: org.scala-tools.sbt#sbt_2.9.1;0.7.7: not found
::::::::::::::::::::::::::::::::::::::::::::::
SBT 0.7.7 uses Scala 2.7.7 for the project configuration. SBT 0.11 uses Scala 2.9.1. You can use SBT 0.7.7 for configurations up to that version, but versions of SBT newer than 0.7.7 use a non-compatible configuration file.
Note that this is not related to the Scala version that will be used to compile the project itself, just the Scala version that is used to compile the configuration file. These are different things: you can use whatever version of Scala you want to compile your project, but you must use the version of Scala mandated by the SBT version to compile the project configuration.
To get an error message like that you must either have changed the Scala version for the project configuration, or used a newer SBT with a project written for an older version of SBT. Find out which it was, and correct the problem as needed.
I have an SBT 0.7.7 for projects that have not yet migrated to the new version, and the latest SBT for everything else. Put a different name on each script, and you are good to go.
While sbt-launch.jar makes an attempt to download and use the version of sbt specified in the project's project/build.properties, they must be compiled with matching versions of Scala. I think sbt 0.7.7 was compiled with Scala 2.7, but the most recent versions of sbt are compiled with Scala 2.9.
Most folks now just use a version of sbt-launch.jar that matches the version specified in project/build.properties. If you're running on Linux, OS X, or pretty anything that can run a Bash script, I highly recommend the launch script from sbt-extras. It will automagically use the version of sbt-launch.jar according to what's specified in project/build.properties, and gives some other handy command line parameters.
If that doesn't work for you, I think your best bet is different launch scripts to launch the different minor versions of sbt. Such as sbt7, sbt10 and sbt11, which launch 0.7.7, 0.10.1 and 0.11.2, respectively.
I have noticed that the issue can be resolved by updating or removing the sbt.version entry from project_root_folder/project/build.properties My current sbt version is 0.11.2 and I have updated it to sbt.version=0.11.2 . Removing the entry also works.
I am try to learn scala with lift. So i started setting up my development environment. After sbt i try install Lifty (i used this article as manual). But i have a problem with my sbt:
> *lifty is org.lifty lifty 1.6.1
[error] Expected ':'
[error] *lifty is org.lifty lifty 1.6.1
[error] ^
Lifty 1.6.x is aimed to be used with SBT 0.7.x. The error shown is due to the fact that Lifty 1.6.x is a SBT processor, while SBT from 0.9.x use plugins instead, so you would need Lifty 1.7.
To get started I would recommend you to use SBT 0.7.7 and Lifty 1.6.1 as there is a lot of information for these and they work beautifully. Please note that Lift has a very active and willing to help community, so you can also ask these questions in the Lift mail list.