I have this problem on an off since quite while without ever understanding what is going on: I import an sbt-based project in IntelliJ, and when running it from within IntelliJ, it seems to be missing project resources (src/main/resources) on the class path, resulting in .getClass.getResource(...) calls to return null.
I tend to delete .idea and create the project anew as I'm suspecting a caching problem from upgrading an existing .idea from previous IntelliJ version. But no luck today. Sometimes changing .getResource to .getResourceAsStream seems to solve it, but again no luck today.
Checking the project settings, the directory is correctly toggled as 'Resources':
And checking the run configuration, the module/class-path is correctly selected:
Needless to say, using sbt test:run from the terminal works as expected, resources are found.
FWIF, here is the run call from IDEA, where I cannot find the resources in the classpath at all:
/usr/lib/jvm/java-8-oracle/bin/java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:47427,suspend=y,server=n -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-8-oracle/jre/lib/charsets.jar:/usr/lib/jvm/java-8-oracle/jre/lib/deploy.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/cldrdata.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/dnsns.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/jaccess.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/jfxrt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/nashorn.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunec.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-8-oracle/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-8-oracle/jre/lib/javaws.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jce.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jfr.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jfxswt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jsse.jar:/usr/lib/jvm/java-8-oracle/jre/lib/management-agent.jar:/usr/lib/jvm/java-8-oracle/jre/lib/plugin.jar:/usr/lib/jvm/java-8-oracle/jre/lib/resources.jar:/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar:/home/hhrutz/Documents/devel/Wolkenpumpe/target/scala-2.11/test-classes:/home/hhrutz/Documents/devel/Wolkenpumpe/target/scala-2.11/classes:/home/hhrutz/.ivy2/cache/com.github.scopt/scopt_2.11/jars/scopt_2.11-3.4.0.jar:/home/hhrutz/.ivy2/cache/org.slf4j/slf4j-simple/jars/slf4j-simple-1.7.18.jar:/home/hhrutz/.ivy2/cache/org.slf4j/slf4j-api/jars/slf4j-api-1.7.18.jar:/home/hhrutz/.ivy2/cache/org.scalatest/scalatest_2.11/bundles/scalatest_2.11-2.2.6.jar:/home/hhrutz/.ivy2/cache/org.scala-stm/scala-stm_2.11/jars/scala-stm_2.11-0.7.jar:/home/hhrutz/.ivy2/cache/org.scala-lang.modules/scala-xml_2.11/bundles/scala-xml_2.11-1.0.5.jar:/home/hhrutz/.ivy2/cache/org.scala-lang.modules/scala-swing_2.11/bundles/scala-swing_2.11-1.0.2.jar:/home/hhrutz/.ivy2/cache/org.scala-lang/scala-reflect/jars/scala-reflect-2.11.7.jar:/home/hhrutz/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.11.8.jar:/home/hhrutz/.ivy2/cache/net.sourceforge.jtransforms/jtransforms/jars/jtransforms-2.4.0.jar:/home/hhrutz/.ivy2/cache/net.htmlparser.jericho/jericho-html/jars/jericho-html-3.3.jar:/home/hhrutz/.ivy2/cache/lucene/lucene/jars/lucene-1.4.3.jar:/home/hhrutz/.ivy2/cache/junit/junit/jars/junit-4.8.2.jar:/home/hhrutz/.ivy2/local/de.sciss/weblaf-ui/2.1.0/jars/weblaf-ui.jar:/home/hhrutz/.ivy2/local/de.sciss/weblaf-core/2.1.0/jars/weblaf-core.jar:/home/hhrutz/.ivy2/local/de.sciss/treetable-scala_2.11/1.3.8/jars/treetable-scala_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/treetable-java/1.3.8/jars/treetable-java.jar:/home/hhrutz/.ivy2/cache/de.sciss/topology_2.11/jars/topology_2.11-1.0.0.jar:/home/hhrutz/.ivy2/local/de.sciss/swingplus_2.11/0.2.1/jars/swingplus_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/submin/0.2.0/jars/submin.jar:/home/hhrutz/.ivy2/cache/de.sciss/span_2.11/jars/span_2.11-1.3.1.jar:/home/hhrutz/.ivy2/local/de.sciss/soundprocesses-views_2.11/3.4.0/jars/soundprocesses-views_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/soundprocesses-core_2.11/3.4.0/jars/soundprocesses-core_2.11.jar:/home/hhrutz/.ivy2/cache/de.sciss/serial_2.11/jars/serial_2.11-1.0.2.jar:/home/hhrutz/.ivy2/cache/de.sciss/scissdsp_2.11/jars/scissdsp_2.11-1.2.2.jar:/home/hhrutz/.ivy2/local/de.sciss/scalaosc_2.11/1.1.5/jars/scalaosc_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/scalacolliderugens-plugins_2.11/1.14.1/jars/scalacolliderugens-plugins_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/scalacolliderugens-core_2.11/1.14.1/jars/scalacolliderugens-core_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/scalacolliderugens-api_2.11/1.14.1/jars/scalacolliderugens-api_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/scalacolliderswing-core_2.11/1.28.0/jars/scalacolliderswing-core_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/scalacollider_2.11/1.18.1/jars/scalacollider_2.11.jar:/home/hhrutz/.ivy2/cache/de.sciss/scalaaudiofile_2.11/jars/scalaaudiofile_2.11-1.4.5.jar:/home/hhrutz/.ivy2/local/de.sciss/raphael-icons_2.11/1.0.3/jars/raphael-icons_2.11.jar:/home/hhrutz/.ivy2/cache/de.sciss/processor_2.11/jars/processor_2.11-0.4.0.jar:/home/hhrutz/.ivy2/local/de.sciss/prefuse-core/1.0.1/jars/prefuse-core.jar:/home/hhrutz/.ivy2/cache/de.sciss/numbers_2.11/jars/numbers_2.11-0.1.1.jar:/home/hhrutz/.ivy2/cache/de.sciss/model_2.11/jars/model_2.11-0.3.2.jar:/home/hhrutz/.ivy2/local/de.sciss/lucresynth_2.11/3.4.0/jars/lucresynth_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/lucreswing_2.11/1.3.0/jars/lucreswing_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/lucre-expr_2.11/3.3.1/jars/lucre-expr_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/lucre-core_2.11/3.3.1/jars/lucre-core_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/lucre-confluent_2.11/3.3.1/jars/lucre-confluent_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/lucre-bdb_2.11/3.3.1/jars/lucre-bdb_2.11.jar:/home/hhrutz/.ivy2/cache/de.sciss/intensitypalette/jars/intensitypalette-1.0.0.jar:/home/hhrutz/.ivy2/cache/de.sciss/fingertree_2.11/jars/fingertree_2.11-1.5.2.jar:/home/hhrutz/.ivy2/cache/de.sciss/fileutil_2.11/jars/fileutil_2.11-1.1.1.jar:/home/hhrutz/.ivy2/local/de.sciss/desktop_2.11/0.7.2/jars/desktop_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/audiowidgets-swing_2.11/1.9.4/jars/audiowidgets-swing_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/audiowidgets-core_2.11/1.9.4/jars/audiowidgets-core_2.11.jar:/home/hhrutz/.ivy2/local/de.sciss/audiowidgets-app_2.11/1.9.2/jars/audiowidgets-app_2.11.jar:/home/hhrutz/.ivy2/cache/com.thoughtworks.xstream/xstream/jars/xstream-1.4.8.jar:/home/hhrutz/.ivy2/cache/com.sleepycat/je/jars/je-5.0.104.jar:/home/hhrutz/.ivy2/cache/com.mortennobel/java-image-scaling/jars/java-image-scaling-0.8.6.jar:/home/hhrutz/.ivy2/cache/com.jhlabs/filters/jars/filters-2.0.235.jar:/home/hhrutz/Applications/idea-IC-16/lib/idea_rt.jar de.sciss.nuages.Demo
Deleting the run configuration and creating it anew "fixed" the problem. It seems to be a bug in IntelliJ, perhaps related to caching or indexing.
The previous broken call was:
java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:47427,suspend=y,server=n \
-classpath ... \
de.sciss.nuages.Demo
The new correct call became:
java -Didea.launcher.port=7534 \
-Didea.launcher.bin.path=/home/hhrutz/Applications/idea-IC-16/bin \
-classpath ... \
com.intellij.rt.execution.application.AppMain de.sciss.nuages.Demo
So while the classpath is same, the launching mechanism is completely different.
Related
I have a question about seemingly unnecessary recompilations by SBT. I have the following scenario: I’m running SBT inside a docker container, by attaching the volume with my application source code to the container, and launching the container with sbt as entry point. If I continuously run SBT inside that container, it doesn’t recompile whole app, which is good.
However, if I start SBT natively on OS X, it does the full recompilation. If after that I start it again inside docker, it again does the full recompilation. It takes very long, and is really annoying. What could be the reason for such behavior?
Here's how I launch the SBT in the container:
docker run --name=bla -it --net=host -v /Users/me/.ivy2:/tmp/.ivy2 \
-v /Users/me/.aws/config:/root/.aws/config \
-v /Users/me/.sbt:/root/.sbt \
-v /Users/me/projects/myapp:/src 01ac0b888527 \
/bin/sh -c 'sbt -Dsbt.ivy.home=/tmp/.ivy2 -Divy.home=/tmp/.ivy2 -jvm-debug 5005 -mem 3072'
My Java, Scala and SBT versions are the same on the host and in the container. Concretely: Scala 2.11.8, Java 1.8.0_77, SBT 0.13.11
Okay, after a day of debugging I've found the way around this problem.
SBT invalidates the compiled classes mainly based on the following rules:
Canonical path
Last modification date
That is, paths and modification dates have to be exactly same for
Source code files
Ivy dependencies jars
JRE's jars
First 2 points are quite easy to achieve, because it's just mapping of docker volumes. The crucial thing is to map to exactly same path as on the host machine. For example, if you work on OS X as I do, path your project sources probably looks like this: /Users/<username>/projects/bla, so in your docker run command you have to do something like:
docker run ... -v /Users/<username>/projects/bla:/Users/<username>/projects/bla ...
You don't care about timestamps for sources and ivy jars, because they will be exactly same (it's the same files).
Where you have to care about timestamps is the JRE stuff. I build the docker image with JRE baked in (using sbt-docker plugin), so I ended up reading modification date of local JRE libs and setting same dates inside the image:
new mutable.Dockerfile {
...
val hostJreTimestamp = new Date(new File(javaHome + "/jre/lib/rt.jar").lastModified()).toString
val hostJceTimestamp = new Date(new File(javaHome + "/jre/lib/jce.jar").lastModified()).toString
runRaw(s"""touch -d "$hostJreTimestamp" $javaHome/jre/lib/rt.jar""")
runRaw(s"""touch -d "$hostJceTimestamp" $javaHome/jre/lib/jce.jar""")
...
}
And, of course, JRE should also be installed to exactly same path as on the host, which might be problematic if you used to install Java from RPM, for example. I ended up downloading server JRE (which is distributed as .tar.gz) and extracting it to the right path manually.
So, long story short, it worked in the end. No recompilation, no long waiting time. I was able to find the relevant information from 2 main sources: SBT source code, particularly this function: https://github.com/sbt/sbt/blob/0.13/compile/inc/src/main/scala/sbt/inc/IncrementalCommon.scala#L271, and enabling SBT debug output in build.sbt:
logLevel := Level.Debug
incOptions ~= { _.copy(apiDebug = true, relationsDebug = true) }
(prepare for a lot of output)
This is just a guess. As rumoku suggest it may be an issue with repositories but I think it's related with SBT itself. From SBT's point of view you are running two different machines and it must compile all when it thinks the files have changed.
I don't know how SBT or the compiler identifies the versions of Scala and Java but it may be the case that even though you have the exact same versions of Java and Scala in both environments SBT thinks they are different. Which makes sense as the are different OS.
I'm trying to build an android project with gradle: it's a library project with ndk flavor, spiced with an external .jar, courtesy of Unity.
I don't really think that the details about the gradle file are important, suffices to say that I'm including the external jar file (provided by Unity) with something like:
dependencies {
compile files('libs/unity.jar')
}
which actually seems to work, as during the java compilation, gradle issues a command like:
BASE="<Some directory>"
javac -d "${BASE}/PluginsSources/Android/libproject/build/intermediates/classes/fat/debug" \
-g -encoding UTF-8 \
-bootclasspath /Users/myusername/Applications/adt/sdk/platforms/android-23/android.jar \
-sourcepath "${BASE}/PluginsSources/Android/libproject/build/tmp/compileFatDebugJavaWithJavac/emptySourcePathRef" \
-classpath "${BASE}/PluginsSources/Android/libproject/libs/unity.jar" \
"${BASE}/PluginsSources/Android/libproject/src/main/java/org/example/ScriptBridge/JavaClass.java" \
"${BASE}/PluginsSources/Android/libproject/build/generated/source/r/fat/debug/org/example/ScriptBridge/R.java" \
"${BASE}/PluginsSources/Android/libproject/build/generated/source/buildConfig/fat/debug/org/example/ScriptBridge/BuildConfig.java" \
-XDuseUnsharedTable=true
indentation and BASE variable added by yours truly. Note that unity.jar is a classpath entry.
Problem is, the compilation fails as javac is apparently unable to find a class in unity.jar when compiling, unless that jar is put into the -bootclasspath option (!!).
Why does this happen? AFAIK, the search path for the classes should be hierarchic and after bootclasspath, javac should be searching classpath...
Is it possible to tell gradle to stick some jar into the bootclasspath somhow (this would clumsily solve the issue)?
Is it there a cleaner/better way?
Thank you for any insight!
EDIT:
After a closer scrutiny, it looks like that classpath works (surprise!) and Unity Technologies didn't create a mutant-classpath-resilient jar as it's first step to take over the world, after all...
The problem was in the path to the compile statement, after replacing it with the correct relative path to the jar, everything worked as expected.
The answers to the question's point are:
Q1: Why does this happen?
Because java cannot find a class in a jar that doesn't exist
Q2: Is it possible to tell gradle to stick some jar into the bootclasspath somhow?
See the answer below
Q3: is there a cleaner/better way?
Yeah: making sure that the path to whatever you are linking is correct might be a good start :)
Note that gradle will not issue any error for missing jars, not even in debug mode (which is an infamy IMHO).
OLD ANSWER
I got to solve the issue myself, somehow (I don't think that my workaround is optimal, but given the attention on this question I guess it's as good as it's gonna get...)
Q1: Why does this happen?
There is no flipping reason, as far as I understand.
The document:
How Classes are Found (Oracle canon)
clearly specifies that the classes in bootstrap are:
Bootstrap classes are the classes that implement the Java 2 Platform.
that is, the classes used to implement the platform. That's why android.jar is there, and unity.jar should not.
Q2: Is it possible to tell gradle to stick some jar into the bootclasspath somhow?
Yes! The following link details how:
Modify bootclasspath in compiler args (gradle forums)
and that is:
allprojects {
gradle.projectsEvaluated {
tasks.withType(JavaCompile) {
options.compilerArgs << "Xbootclasspath/a:src/main/libs/unity.jar"
}
}
}
which, in my projects maps to loading a unity.jar archive after the android one, located in the src/main/libs directory of my android library.
Q3: is there a cleaner/better way?
I don't think so, at least not without understanding why the jar needs to be in bootstrap in the first place (which would make most of the issues here pointless): changing the bootstrap classpath is not something the high level programmer should do, so I don't expect gradle to provide a cleaner shortcut.
I'm still waiting for someone with some insights about the issue (I can't sink more of my time on this), but I hope this will help someone anyway.
I am using intellij 14 with scala 2.11.6 installed using home brew and symlink using
ln -s /usr/local/Cellar/scala/2.11.6/libexec/src /usr/local/Cellar/scala/2.11.6/src
ln -s /usr/local/Cellar/scala/2.11.6/libexec/lib /usr/local/Cellar/scala/2.11.6/lib
mkdir -p /usr/local/Cellar/scala/2.11.6/doc/scala-devel-docs
ln -s /usr/local/Cellar/scala/2.11.6/share/doc/scala /usr/local/Cellar/scala/2.11.6/doc/scala-devel-docs/api
I tried running a simple hello world but run into the following issue.
Error:scalac: Multiple 'scala-library*.jar' files (scala-library.jar, scala-library.jar, scala-library.jar) in Scala compiler classpath in Scala SDK scala-sdk-2.11.6
Edit:
So I check the compiler class path on global libraries and apparently there are multiple scal-library.jar
file:///usr/local/Cellar/scala/2.11.6/idea/lib/scala-library.jar
file:///usr/local/Cellar/scala/2.11.6/lib/scala-library.jar
file:///usr/local/Cellar/scala/2.11.6/libexec/lib/scala-library.jar
Does anyone know why?
Maybe you have used
/usr/local/Cellar/scala/2.11.6/
as the path for Scala SDK?
When you install scala with homebrew that path will contain not only the scala libraries, but also a symlink with the relevant libraries for intellij. So if you use the top-level install directory intellij will find the libraries twice.
Instead you should use
/usr/local/Cellar/scala/2.11.6/idea/lib
I had the same issue than you experimented and the solution, actually very easy, was actually erasing the .idea folder from the project, the problem is that the configuration inside of this folder (containing the set ups for example for the test, VCS, the runs, etc) gets corrupted with double entries (probably cos you update your Scala version), once you do this and reopen the project in Intellij the IDEA will generate a fresh new configuration for you.
This worked for me.
I'm using Idea 2019.2.2 and Windows 10.
In the folder .idea/libraries/ I had two files: sbt__org_scala_lang_scala_library_2_13_0_jar.xml and sbt__org_scala_lang_scala_library_2_13_0_jar2.xml.
I deleted the second file.
Then I opend the first one and there were duplicate lines:
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/jline/jline/2.14.6/jline-2.14.6.jar" />
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.13.0/scala-compiler-2.13.0.jar" />
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.13.0/scala-compiler-2.13.0.jar" />
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar" />
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.0/scala-library-2.13.0.jar" />
<root url="file://$USER_HOME$/AppData/Local/Coursier/cache/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.13.0/scala-reflect-2.13.0.jar" />
So I deleted duplicates and errors disappeared.
Hope this will help someone else.
I also ran into that error. The fix I found was to remove the duplicate scala-library in the .iml file generated by intellij.
Basically I located the relevant .iml file by grepping the scala version, and found that two scala-library in that file. I removed the scala 2.11 version, and then it works.
Remove the following line in build.sbt:
...
scalaVersion := "2.13.0"
...
Try rebuilding and running it again
2019 update... I'm running Ubuntu Linux and IntelliJ community 2019.1 with sbt 2.13.1 and got the exact same error. I also found that if I built directly from sbt with "runMain package.MyClass" it worked, so I knew it must be an IntelliJ problem, not a "real" problem.
Anyway, I found the file .idea/libraries/sbt.. lots of crazy long name ... scala_library_2_13_1_jar.xml.
In it, there was an XML block , and in that block, two entries were duplicated:
I first noticed the scala-library one, and after deleting that, the error report came up about the scala-compiler duplicate too.
After deleting both duplicates, my build is now working.
To fix the problem go to project structure in intellij and go to global libraries
It should be like this
After that remove all the scala SDKs by hitting the - mark
Next, click the + and choose your Scala SDK version to add
After that please make sure to apply the changes and re-run the program
You have JAR files from multiple versions of scala-library.jar. In order to make the error go away you will have to delete the duplicates. To figure out which version you want to keep, you can view the manifest file inside each JAR:
META-INF/MANIFEST.MF
Inside the manifest file you should see something like this:
Manifest-Version: 1.0
Class-Path:
Implementation-Title: Scala-Library
Implementation-Version: 2.11.4
The error is happening because IntelliJ cannot figure out which version of a given Scala class to use.
Delete multiple versions of scala-library in sbt, leaving one.
Having similar symptoms, but on a Ubuntu machine, not using brew:
I am using /usr/share/sbt/bin/sbt-launch.jar as launcher. To fix the mentioned problem, I've had to purge the directories 1) project, 2) target and 3) .idea of the relevant Scala projects, doing sbt refresh in IntelliJ (View - Tool Windows -> sbt, hit the Reimport all sbt projects icon), and rebuild all modules afterwards.
As a last step, when the error occurs further, switch over to Ubuntu shell / terminal, and do a sbt clean compile in the problematic project folder. Fix the compile issues if some are occuring. If this does not help, change scalaVersion in build.sbt e.g. from 2.12.9 to 2.12.8 (the error occurs more often with 2.12.9), remove scalaOrganization definition (but keep organization). Repeat the sbt refresh of IntelliJ. OMG.
This worked for me:
In IDEA
Preferences -> Plugins -> Scala -> Update
Restart IDEA
I've created a play project with play 2.3.7
In the project directory, I ran activator and ran the eclipse command to generate eclipse project files.
When I go to eclipse (I'm using the Scala IDE from typesafe Build id: 4.0.0-vfinal-20150119-1023-Typesafe , there is an error in my Application.scala file:
object index is not a member of package views.html
Is there something amiss with my setup? The app runs fine when I execute run at the activation console prompt.
Thanks!
EDIT: Added code
package controllers
import play.api._
import play.api.mvc._
object Application extends Controller {
def index = Action {
Ok(views.html.index("Your new application is ready."))
}
}
The error is on the 'Ok..' line.
There is a file in views called index.scala.html, and the app runs file when I run it from activator..
Occasionally after adding a view in Play 2.4.x, IntelliJ IDEA sometimes gets confused and absolutely refuses to build. Even rebuild Project fails:
This still happens from time-to-time in IDEA 15. And when it does, the command line provides the quickest, most-reliable fix:
sbt clean; sbt compile
That's it! IDEA will now compile the project as expected.
Update:
In the rare case that sbt compile completed successfully on the command line, but IntelliJ IDEA 15 still gives the same "object x is not a member" error, then this has solved IDEA's confusion:
File Menu:
The other solutions did not work for me. Some would give me different errors, some would clear the Problems tab but leave me with a red squiggle under views.html.index and auto-complete would not work with the scala.html templates.
What finally worked was to open the project's properties, go to Java Build Path > Source, and add both of the following directories:
target/scala-2.11/src_managed/main
target/scala-2.11/twirl/main
If you only do target/scala-2.11/twirl/main then you'll miss out on the class files generated from the conf directory.
In Scala IDE 4.0.0 thinks there's errors in an out-of-the-box Play Framework 2.3.7 program you can find the solution (in brief: adding target/scala-2.11/twirl/main folder to the compilation path), give it a try.
I had the same problem. I added target/scala-2.x/classes and target/scala-2.x/classes_managed to my Java build path and Eclipse stopped complaining.
Adding target/scala-2.11/twirl/main which is having views.html package to source fixed for me.
I had the same issue running Play 2.4.0-RC1 using default SBT layout (disablePlugins(PlayLayoutPlugin)) and solved it by adding to build.sbt:
sourceDirectories in (Compile, TwirlKeys.compileTemplates) :=
(unmanagedSourceDirectories in Compile).value
#brent-foust 's answer worked for me but only initially. Every time I rebuilt the project from within IDEA I would then get "not found: routes" errors from within target\scala-2.11\twirl\main\views\html\main.template.scala until I performed Brent's workaround again.
I eventually discovered the solution to that was changing a line in the .iml file from
<excludeFolder url="file://$MODULE_DIR$/target/scala-2.11/src_managed/main" />
to
<sourceFolder url="file://$MODULE_DIR$/target/scala-2.11/src_managed/main" isTestSource="false" />
I don't know what the long term implications of doing this are but it has fixed this problem. Some of the other similar problems mentioned might also be fixed by applying the same change to some of the other folders listed in the .iml.
I tried all solutions without any positiv result.
So I went to Preferences > Build, Execution, Deployment > Build Tools > sbt and checked Use sbt shell for imports and builds.
This let the compile button in intelliJ compile with the sbt shell.
I think this is better anyway, since a build server or something similar will compile the same way and not like intelliJ.
For me when importing the project into intellij making sure I "checked" the "auto import" checkbox did the trick.
1) Add the following line to your sbt.build file:
EclipseKeys.preTasks := Seq(compile in Compile)
2) Add the follwing line to your plugins.sbt file under the project folder:
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "5.1.0")
3) Run the "eclipse" command from within sbt
as explained in the documentation of the play framework:
Setting up your preferred IDE
Basically we need a way to put the compiled classes on the path for this to work.
I did the following to fix it.
Since the projects compiles to the target directory.
I went to the Project Properties -> Java Build Path and added a few folders that look like this,
target/scala-2.12/routes/main
target/scala-2.12/twirl
target/scala-2.12/twirl/main
Now i dont want you to assume you will have these exact folders in your case too. That depends on your project setup.
But you should add the folders inside the target/scala-2.x folder.
I successfully implemented and ran several Scala tutorials in Eclipse using the Scala plugin. Then suddenly I tried to compile and run an example, and this error came up:
Exception in thread "main" java.lang.NoClassDefFoundError: hello/HelloWorld
Caused by: java.lang.ClassNotFoundException: hello.HelloWorld
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
After this point I could no longer run any Scala programs in Eclipse. I tried cleaning and rebuilding my project, closing and reopening my project, and closing and reopening Eclipse.
Eclipse version number 3.5.2 and Scala plugin 2.8.0
Here is the original code:
package hello
object HelloWorld {
def main(args: Array[String]){
println("hello world")
}
}
If you see this when you attempt to run as a Scala application then the most likely explanation is that your project didn't compile and no class files were generated. Please check whether or not that's the case: look in your project's output folder for hello/HelloWorld.class.
If your project didn't compile that could either be because there's an error which you've missed (and if this error isn't being reported in the Problems view that could be a bug, in which case please open a ticket on Trac) or because you've turned off automatic builds and not done a manual build of your project.
I had the same problem. Project doesn't compile but there are no errors highlighted and AFAIK the code is OK. It seems to be a problem with the Run Configurations.
Solution 1: Delete the existing Run Configuration for your object and create a new one
Solution 2: Create a new object and cut / paste all your code into that file
When running "clean" does not un-hose Eclipse, I next try saving my work, exiting Eclipse, and re-starting. That usually gets things going again, but not always. A few times I've had to update the Scala plugin with a more recent version (I'm using the latest nightly), to get things working again. I doubt that this worked because the new plugin happened to fix the bug, but rather expect that loading the new plugin gives the whole Eclipse-Scala
system a "total reset" that gets it unhosed.
I was getting this problem in a project that combined .java & .scala files.
The solution for me was:
Remove all .java files
Edit the scala code as needed so it compiles without them.
Add the .java files back in.
Edit the scala code back.
The other solutions given here didn't work for me. I tried: clean project, restarting Eclipse, closing-&-opening the project, creating a new .scala file. No joy.
I'm using Eclipse 3.7 (latest stable), Scala IDE 2.0.0 and Scala 2.9 on Ubuntu Linux 11.10.
The symptoms in my case were:
My project was working, but then it stopped compiling for no apparent reason. The IDE didn't show any compilation errors for .scala files, but there were no .class files in the output directory & I got a NoClassDefError if I tried to run anything.
If I created a deliberate error in a .scala file, that did get picked up as a compilation error.
The .java files were registering errors due to the missing scala classes.
I suppose there's probably a boot-strapping bug somewhere in the IDE plugin for .java/.scala mixes. I've done hybrid projects with this setup without problems, so it's only triggered in some situations. I don't know what the trigger is, but once triggered, there's no nice solution.
I had moved my one and only class/object/application to a package, but had not added the package declaration.
sbt compiled and ran fine; eclipse would not
Adding the package declaration at the top of the file fixed it.
Scala 2.8.3 plugin; no compile error
I encountered this error too but after doing the suggestions here (cleaning, deleting Run Configuration etc), I realized that I set the workspace wrongly that is why the class is not being found.
An indication that this is a problem is when the same error occurs when you try to compile a java project.
I encountered this error (compilation worked in sbt but failed in eclipse) when I created a new package object called "common". Deleting the package object in eclipse caused the compile error to go away. There was nothing in it.
I was using sbt-eclipse to build the eclipse project. I'm using scala eclipse 3.0.0-vfinal-20130326-1146-Typesafe.