I\'ve got a scala project that compiles, runs and tests fine when using SBT from the command line. However, when building the project in intellij, it seems every class in the pr
In my case problem solved by change ScalaTest template configuration in Idea. I select use sbt
, disable print info
, remove build before launch.
I like to use SBT for clean/package/test on specific module. I also use mixed Java/Scala classes in test (but I replace compile order to Java than Scala
).
At least now I can test from IDE withot this error.
PS: Now I disable use sbt
. My tests work fine (but I'm not sure, that they will work).
PPS: New tests not runs before compilation. It is disadvantage of removing build (and, maybe, of disabling use sbt
). But this extra build cause problem with dublication, as I think
I had the same problem and @Max is right, there is a conflict with the compiled classes, but the solution provided didn't work for me. It turns out that I was using sbt-idea to generate the IDEA project structure as a workaround of an Intellij IDEA 14 + scala plugin bug on the SBT import, that is not fixed yet at the time I write this.
In order to fix it, I had to remove src_managed/main/controller
that was in conflict with src_managed/main
in the Module settings because of an sbt-idea bug. So double-check your module source folders and make sure you don't have subfolders in conflict with a parent folder already declared as source.
I had a similar issue repeatedly both within Idea and without: plain SBT.
It turned out that CVS stores copies of some *.scala files in subdirectory CVS/Base, which SBT apparently tries to compile. The problem went away when I deleted the CVS subdirectories.
I'll just add mine to the list in case anyone else made this beginner mistake: I temporarily "saved my progress" by doing cp Foo.scala Foo-save.scala
, forgetting that sbt would try to compile all the .scala
files in the directory.
(I don't know, I guess I was thinking of programming languages where any file not explicitly include
d was ignored ...)
Of course, since both the main file and the "temporary backup" file defined the same classes ... yeah.
Do you have any other files in your project with an SendCommandToService
in them?
You could try renaming it to something else, see if that works
If you want to keep the same names, you can put them into separate packages.
Or have them in different encapsulating objects
object traitdemo{
object Ex1{
...
}
}
object otherdemo{
object Ex1 {
...
}
}
that will work even in the same file
After the sbt compile I had to mark the folder as Generated Sources Root because I needed those files for compilation.