0

I'm experiencing a problem when running latest play framework 2.3. It compiles just fine, although when I do activator run this error happens:

java.lang.NoSuchMethodError: scala.Predef$.ArrowAssoc(Ljava/lang/Object;)Ljava/lang/Object;

Full error log

I explicitly tried scalaVersion in every build.sbt file and it is the same. I tried several things like activator clean, full removal os sbt caches and local repo sbt stuff, updating dependencies to latest version but no success. I have scala version defined.

My current dependencies are: I tried with both %% and force _2.11 in the name of the dependency.

Dependency List

Other important files

build.sbt

Common.scala

Dependencies.scala

When I fully clean caches it downloads scala 2.10.4 for no reason: in this download log it says the sbt need the old scala. Any idea why is this?

Any ideas?

rtfpessoa
  • 521
  • 2
  • 16
  • You are using the `ws` dependency as provided by Play, but you are importing the JDBC and JSON libraries seperately. Why is that? – DCKing Jun 13 '14 at 12:52
  • That is for a sub project that doesn't need all the play. – rtfpessoa Jun 13 '14 at 12:55
  • This seems relevant: http://stackoverflow.com/questions/13098856/how-to-fix-nosuchmethoderror . What if you add `scalaVersion` in more places? – DCKing Jun 13 '14 at 13:08
  • I tried with scalaVersion explicitly in every build.sbt file and it is exactly the same. – rtfpessoa Jun 13 '14 at 13:10
  • DCKing I just added a log of the downloads, do you have any idea why is that? – rtfpessoa Jun 13 '14 at 13:37
  • Your build is rather complex; it seems likely that something is triggering some sort of default behaviour for SBT. Does the [debug information](http://www.scala-sbt.org/0.13.5/docs/Howto/logging.html) tell you anything? – DCKing Jun 13 '14 at 13:47
  • The `last run` is what i first published as the log. It has the full log. And it explodes outside my code, thats what makes this strange. – rtfpessoa Jun 13 '14 at 14:03
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/55574/discussion-between-rtfpessoa-and-dcking). – rtfpessoa Jun 13 '14 at 14:09

3 Answers3

1

Firstly, it does not matter which version of Scala is used to generate your build. The build system can use version 2.10.4, and that does not prevent your code from using version 2.11.1.

To look at the issue with your scala version, you should consider that settings added directly in build.sbt are added to the root project, but not to other projects. You can see this with a minimal project such as:

$ cat build.sbt
scalaVersion := "2.11.1"

lazy val subproj = project in (file("subproj"))

Then the output of sbt looks like this:

> show scalaVersion
[info] subproj/*:scalaVersion
[info]  2.10.4
[info] sbttest/*:scalaVersion
[info]  2.11.1

So, how can this be fixed?

We can create a lazy val containing a Seq[Setting[_]], and add it to the sub-project definition with the settings() method.

Here's an example build.sbt which adds the same settings to all projects:

$ cat build.sbt
lazy val root = project.in(file("."))
  .aggregate(subproj)
  .dependsOn(subproj)
  .settings(commonSettings: _*)

lazy val subproj = project.in(file("subproj"))
  .settings(commonSettings: _*)

lazy val commonSettings = Seq(
  scalaVersion := "2.11.1"
)

The _* is required because settings() is defined as requiring Setting[_]* rather than Seq[Setting[_]], so _* converts between the two types. See also: What does param: _* mean in Scala?

And the output from sbt is:

> show scalaVersion
[info] subproj/*:scalaVersion
[info]  2.11.1
[info] root/*:scalaVersion
[info]  2.11.1

This approach can easily be applied to your build.

Community
  • 1
  • 1
Gary Coady
  • 1,196
  • 9
  • 13
  • In fact I have that. The difference is that instead of placing the version in the main build.sbt I have it in all of them when I import my Commons.scala. So I think your answer doesn't add much to the problem. As I explained before I even tried to put it in every file. So its not a missing version import. In fact when compiling it says explicitly that each component is 2.11. Still I do not find the real error. Any ideas? – rtfpessoa Jun 14 '14 at 17:46
  • 1
    Going by your sample build.sbt, one sub-project is: lazy val precog = project.in(file("components/precog")).dependsOn(frameworkDependency, dependencyBuilder).aggregate(framework, dependencyBuilder) Note that this has _no_ settings defined. Importing Commons._ does not help unless you also add it to the project, e.g. lazy val precog = project.in(file("components/precog")).dependsOn(frameworkDependency, dependencyBuilder).aggregate(framework, dependencyBuilder).settings(appSettings: _*) i.e. the main difference here is to explicitly add appSettings to the project via the settings() method. – Gary Coady Jun 14 '14 at 17:56
  • Ok, your are not understanding what I'm saying. In the subproject build.sbt i have appSettings. Althought even if what I'm saying was wrong, i tried your command and i got all the subprojects version as 2.11.1. So that is not the problem for sure. Do you have any other ideas? For example i have a sub project that is a play project too, should it have any difference in his build.sbt? – rtfpessoa Jun 14 '14 at 18:00
  • 1
    Is the copy of build.sbt mentioned in the question out of date? Because if I take the files you provided, I can see that some projects have a scalaVersion of "2.10.4". If I make the suggested changes, all projects have a scalaVersion of "2.11.1". Importing the Commons.scala file that you provided, will not automatically apply those settings to sub-projects. It will only apply them to the root project. – Gary Coady Jun 14 '14 at 18:06
  • As I said that is only the build.sbt of the main project. The others import Commons._ and have `appSettings` in the body so that it expands the settings. Still, to make sure, I just converted into your way (that is more organised in fact) but I receiver exactly the same error. BTW the error may not be about the version I just said that because the version errors are very similar to this one. Any other ideas? – rtfpessoa Jun 14 '14 at 18:09
  • If you want you can come here: http://chat.stackoverflow.com/rooms/55574/discussion-between-rtfpessoa-and-dcking and we can have a better chat. This is more a comment space. – rtfpessoa Jun 14 '14 at 18:13
  • 1
    Can you run "show scalaVersion" from sbt? This will show what scala version your projects are expecting. All lines should say "2.11.1", or that project is not picking up your settings. (I don't have enough reputation to use the chat interface). – Gary Coady Jun 14 '14 at 18:14
  • I said 3 answers above i did that. And every line says version 2.11.1. None of them 2.10.4. – rtfpessoa Jun 14 '14 at 18:16
  • 1
    Okay, then at least we know that the version settings are working. Also, I have seen an issue like this before when a libraryDependency pulled in an old version of scala-library. Try "show libraryDependencies" and see if there are any _2.10 libraries included? "scala-library:2.10.4" would be an especially bad thing to have in the list. – Gary Coady Jun 14 '14 at 18:19
  • Just tested the: `show libraryDependencies`, but it seems that it just shows my explicit dependencies and they are all 2.11. It doesn't show recursive dependencies. – rtfpessoa Jun 14 '14 at 18:22
  • 1
    Ah. Can you try https://github.com/jrudolph/sbt-dependency-graph - then run "dependencyTree". To give the reason why this kind of thing could cause a problem: I've seen an issue where a scala 2.9 build pulled in akka 2.x, which itself transitively depended on scala-library 2.10. The result was an error finding a basic scala class (Option). – Gary Coady Jun 14 '14 at 18:29
  • Just tested. It has errors, it says there is a missing file for some sub projects and each time I run, the sub projects are different. What can this be? – rtfpessoa Jun 14 '14 at 18:50
  • It seems to be related to concurrency. After disable concurrency the dependencies worked but there is no 2.10 all of them are 2.11. Any ideas? – rtfpessoa Jun 14 '14 at 18:57
  • Fiadliel i just found that some deps use 2.11.0 not 2.11.1. Can this be the problem? `+-org.scala-lang:scala-library:2.11.0 (evicted by: 2.11.1)` – rtfpessoa Jun 14 '14 at 18:59
  • just tried to change scalaVersion to 2.11.0, it compiles but still the same error. – rtfpessoa Jun 14 '14 at 19:08
  • 1
    Perhaps if we go back to basics, the issue looks like an incompatibility between play libraries and scala libraries on the classpath - nothing else should generally matter. If you look (carefully) at the output of "show fullClasspath", there should only be one scala-library-2.11.x.jar, and no other versions; there should also only be one play_2.11-2.3.0.jar, and no other play (e.g. play_2.10). – Gary Coady Jun 14 '14 at 19:33
  • 1
    One other thing to try: do "sbt dist", to create a distributable archive file. It might make it easier to dissect which library versions are being included in the build. – Gary Coady Jun 14 '14 at 19:34
  • After the dist there seem to be conflicting jars in the folder: http://pastebin.com/yBdJFd8n Any idea why? – rtfpessoa Jun 14 '14 at 19:40
  • someone added jars manually to the lib folder. That was probably it (have no idea why?). I'm testing now. Sorry for the trouble and many many many thanks for your help. Just upvoted your help, hope you grow fast in here. Very kind and pacient :D – rtfpessoa Jun 14 '14 at 19:55
  • 1
    Great to know you figured it out! It will be useful to (eventually) get the ability to use that chat thing. One more thing: the resolution-cache files mentioned in the chat might have been useful. But the "*-runtime.xml" file you posted came from the "project/target/resolution-cache/reports" directory, which shows the build configuration (useful if the build fails). You should look at the "*-runtime.xml" file from "target/resolution-cache/reports", and it might have shown the issue with the runtime classpath. – Gary Coady Jun 14 '14 at 20:00
  • Thanks, since i accepted the answer and upvoted it you now have 26pts and can chat. :D – rtfpessoa Jun 14 '14 at 20:05
0

The problem was related to some manually added jars that I discovered in the lib folder, that were causing issues with the dependencies of the project defined in the build.sbt. The only way to find out was to generate a activator dist and look for similar dependencies with different versions since in the dependency graph there were no conflicts

rtfpessoa
  • 521
  • 2
  • 16
0

You're defining your dependencies in the wrong way.

When using SBT, don't use:

"org.mydep" % "mydep_2.11" % "1.0.0"

Instead use:

"org.mydep" %% "mydep" % "1.0.0"

The %% operator automatically appends the current Scala version of the current build. If you use dependencies built against other Scala versions, you're going to be getting the weird errors.

Also make sure you explicitly specify your Scala version somewhere:

scalaVersion := "2.11.1"
DCKing
  • 4,253
  • 2
  • 28
  • 43