I have a JUnit test class in my project which is updated incrementally - I add tests every few weeks and sometimes modify the tests' code.
Surprisingly, when I run the test class using eclipse JUnit Runner 4, it runs my old code (before the update) and not the new one. I can change the code, add or remove tests but it still runs the old code.
I tried to isolate the problem and run a single test that I've just written and got the infamous "Unrooted tests" error without any stack trace to give me a clue what the problem is.
I did some research and according to a few other threads here, many people encountered this problem with regards to JUnit 3 \ JUnit 4 compatibility, but this is not the case here - I annotate all my tests with #Test and I do NOT extends the TestCase class.
Cleaning / Building all eclipse projects doesn't help.
However, this problem does work itself around when I mvn clean install my project, but this takes too much time.
Also, renaming the class (Alt+Shift+R in eclipse) gets the new code to run immediately, but renaming it back to its original (and valid) name, gets the old code to run again (WTF?)
Help would be appreciated,
10x
I managed to solve the problem on my own (inspired by a comment contributed by Harlard).
After examining the target directory of my project, I noticed that the test-classes dir inside it doesn't include the binaries of my test.
I then noticed that I misplaced the classes within src/test/java and put them in a package structure that doesn't conform to the package structure of my project, they were direct sub-directories of src/test/java.
Therefore, eclipse didn't put them in the correct place and the only way to generate binaries for them was by executing a maven build.
After refactoring all my test classes to the correct package structure, everything worked perfectly.
I had the same issue. It was due to a defective .classpath. Removing this .classpath and re-importing the project, generates a correct .classpath and fixed the environment.
Another solution would be manually deleting the "target" folder of the project and rebuilding it. This should solve all problems of this kind.
Related
I am running into a problem when trying to duplicate a project in STS.
I am getting lots of error-messages of type
"Import XY cannot be resolved..."
in my code which runs and builds completely fine with maven and which is a more or less exact copy of the original project (with different artifact ID a.s.o. in the corresponding pom) which is shown as error-free.
What I did until now:
I wasn't sure how STS-duplicate works and thought that some configuration may have been duplicated but would have needed some changes, so I created a new project and inserted the code manually in manually new created classes and added the needed dependencies to the pom.
Again this compiles and runs perfectly while still showing the import errors.
Did anyone run into similar problems and has a solution to this?
(I had something similarly strange in the past where STS showed an error on project-level but no file in the project would have an error-indicator.)
Run a Maven -> Update Project..., that should help... :-)
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 project has this error in the event log, causing the build to fail:
SendCommandToService is already defined as case class SendCommandToService
case class SendCommandToService(service: String, commandName: String, keys: Array[String], values: Array[String])
^
For me, the reason is that both myproject/src and myproject/src/main/scala are marked as Source. So IntelliJ failed to build myproject/src/main/scala due to above errors. Unmark Source from myproject/src (in IntelliJ, File->Project structure, select myproject Module, select src folder in Sources Tab, remove it from Source in the "Add Content Root" pane) solved the problem.
It means there are two compiled classes with identical package and class name found in your classpath. One compiled by sbt, one compiled by IntelliJ.
One of the following should be able to solve the issue:
try to generate IntelliJ .iml file with sbt-idea rather than import directly.
sbt clean before click Build -> Rebuild in IntelliJ
when rebuilding with IntelliJ, make sure sbt is not running
I ran into this issue today on IntelliJ 2021.2.1 and according to this page it's some issue with IntelliJ's incremental compiler for Scala, so the solution is to change the "Incrementality Type" from "IDEA" to "Zinc" in Preferences -> Build, Execution, Deployment -> Compiler -> Scala Compiler
For me, the solution was to double check the source folders in each of my modules in IntelliJ.
File > Project Structure > Modules and for each module, double check that the Source Folders only contain your intended folders, e.g. src/main/scala, and do not contain any generated sources (e.g. target/scala-2.12/src_managed/main.
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.
You need to change "Settings -> Build,Execution,Deployment -> Scala Compiler -> Compile order" from "Mixed" to "Java then Scala".
If you have compile the project previous, you should first run "sbt clean".
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.
Problem is caused by duplicated line in .idea/modules/<your_project_name>.iml file. Check if you do not have duplicated <source_folder> tag.
In my case I had the same problem with all classes in src/test/scala path, and after removal duplicated tag for this path, project build fine.
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
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
File -> Invalid Caches/Restart worked for me. All other answers here did not.
After the sbt compile I had to mark the folder as Generated Sources Root because I needed those files for compilation.
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 included was ignored ...)
Of course, since both the main file and the "temporary backup" file defined the same classes ... yeah.
I had the same error message and it turned out that IntelliJ for some reason created duplicate copies of some existing source files. For example I had a file Attribute.scala that was tracked with git and then there was an untracked file Atrribute 2.scala with the same contents in the same directory (which I never created). This was of course a problem, because the compiler considers them part of the project, hence the duplicate object definition error.
I am not 100% sure when this happened (I suspect it was during git rebase). So, if you run into this problem again, it's also worth checking with git status if you have some untracked files which duplicate contents of tracked files.
Remove the untracked files and the problem is solved.
Kudos to this question thread, it helped me to solve this issue.
My case is a project with the mix of Scala, Java and Avro schemas.
IDE: IntelliJ IDEA 2022.1.3
How I solved it step by step (in IntelliJ):
File -> Project Structure
Project Settings -> Modules
Now we need to fix the "source" files. I searched for target/scala-2.12/src_managed in each module and marked it like “Source directory” (blue colour).
Unmarked all other paths like target/scala-2.12/* in all modules (in my case it was target/scala-2.12/src_managed/main/compiled_avro). As an example from my project, I left only these sources in one of the modules: target/scala-2.12/src_managed , src/main/scala.
Save the changes and rebuild the project.
ADDITION: Oh, and looks like sometimes this error occurs when you compile your scala project (with avro files) outside of the IntelliJ. For example when you build a project using sbt externally and then run some tests using the IntelliJ -> class already defined error occurs (or is not a member of package error). In such case: you need to run sbt clean compile externally first and go to step #1.
this happen when you incorrectly src/main/any other folder as Sources Root. Please check if you have any such cases. If yes, then Unmark those by righclick on it. then clic one level above of your groupId starting. Lets say your package is com.company.test and com may comes under java or scala, then right click on that(java/scala) then Mark as Sources Root.
In my case, the problem was the protobuf Idea plugin:
Remove the idea protbuf plugin.
Close Idea
Remove all folders related with idea (.idea and .idea_modules)
Open Idea and Import the project again.
I had a package structure which I changed, and this lead to the corresponding folders in /bin/ being removed, so now I get a ClassNotFoundException.
More specifically, I had the ususal /src/ and /bin/, and inside /src/ I had /main and /test, and this was presumably mirrored in /bin/. I shuffled the files around a bit and ended up with /main/model/ and /test/model/.
I have tried to manually create the corresponding folders (mirroring the packages in /src/), but this does not seem to help. I managed to compile the classes in one of the packages, but not in the test package, since it uses ScalaTest* and I didn't manage to compile the classes with the scalatest jar file (or something was wrong with the classpath).
So my question is:
How do I fix this within this peoject? (I don't want to simply create a new project and copy the source files over)
I'm guessing that I should learn more about build systems to be more resilient to such annoyances in the future? If so, what should I read up on, specifically to become better at troubleshooting and having more fine grained control over the build in the context of IDEs in the future (making builds independent of IDEs is not a priority for me at this point)?
An answer to one of these questions would be sufficient.
*All the source files are .scala files, if that might matter.
Udate
I did a clean of the project (project -> clean). This seemed to fix the problem: I was able to run the test classes from within Eclipse. All the binary files were in there, too. I made a new package, main.controller, with one class, and when I tried to run it, it said that it couldn't find the class. I tried to run the tests again, but those gave me a ClassNotFoundException, too. When I looked in /bin/ it turned out that all the folders and files were gone. I've tried to clean the project again but to no avail. I don't understand how I was able to clean the project, but now it can't fix it?
Update 2
To test if this was reproducible with a Java project, I made a Java project with two packages; main and test. I had the main class in main, which used a class from test (so there were dependencies across the packages). It ran succesfully. Then I added packages so that I had main.model and test.model and moved the corresponding files there. It also ran. Then I tried to delete all the files and folders in /bin/, and then the main class would not run. But if I did a clean of the project, then it cleaned it succesfully and the Main class was able to run. Then I made a Git repository for it, placing it outside of /workspace/ (in my git folder) and tried to do the same there. Eclipse was able to clean the project succesfully everytime.
So I don't understand why it can't manage to clean my Scala project.
I had errors in the "Problems" tab (Window -> Show View -> Problems). Now that I've made them go away, my /bin/ is correct and I can run both my Main class and my tests. This Question helped find out what the problem was:
Scala project won't compile in Eclipse; "Could not find the main class."
Problem: I cannot setup Run Configurations to run scalatest for the Scalatests in my project.
Steps to reproduce:
Right click on Scala Suite and click on Run as -> Run configurations..
On the left, I see a configuration template for ScalaTest. I click on New and fill the Name but it cannot find the suite-class.
Note: It is mentioned here that I should see Run as -> ScalaTest - Suite but I do not see that option. I tried using context menu in the editor, and in the package explorer
Steps taken:
Using: Scala IDE for Eclipse version: 2.1.0.m3-2_09
Using SBT, assemble project, run eclipse command and then import project and dependencies into Eclipse
Project compiles. ScalaTest code compiles(scalatest_2.9.2-1.8.jar is in the 'Referenced Libraries' configuration)
I've been fighting a similar problem for the past few days; Lily / Jimbo's answer didn't quite match my situation, but helped me find the right direction.
In my case, I was using a third-party library that I'd copied in. The package names of the classes and tests matched, but the folder structure did not -- all of my tests were directly in Play's "/test" folder, rather than in folders that matched the package names. This didn't show any errors, but was broken: packages ought to match folders. When I built the right folder structure underneath test, and recompiled, the expected "Run As -> ScalaTest - Suite" options showed up.
Don't know if your problem is the same, but you might check this if you haven't already found the issue...
This could be caused by a misalignment between the scalatest and the scala eclipse IDE version. Try scalatest_2.9.0-2.0.M5b.jar or scalatest_2.10-2.0.M5b.jar. The former jar definitely works with ide 2.0.9.x so maybe the new version needs the 2.10 jar. Pick your version carefully from here
Willem's answer is what worked for me. Getting both plugins from the same update site (from the list on Scalatest's github site), seemed to work for me using Kepler.
for my case, one click on 'Reimport All Maven Projects' icon, like 'Refresh' icon, solved the problem.
Not sure if you fixed the error, but I had similar a error yesterday and was pulling my hair trying to fix it (none of the suggestions I found by googling seemed to help me). So for me, it turns out that it's as easy as package hierarchy in my test suite.
I am using the play framework, so naturally my folders look like this controllers.package1.package2.... and this applies to my test folders also.
Now my test classes however, have the package definition package1.package2..... (no "controllers" as prefix).
If I run the tests on sbt/play command prompt, it's not a problem. But running them through Eclipse would give me the problem you described.
So anyways... thought I'd share this, in case this could help.
it's a bit annoying combined with the view template compile issue in play framework. but my approach is to regenerate the eclipse project file and add view template path into the class path
In Eclipse with groovy plugin, I try to launch a test #Test public void testToLaunch() {...} but I have the error:
The input type of the launch configuration does not exist
What input type is in the context of launch configuration? (can't find such an entry in launch configuration window)
Note: I try sts 2.8.1 and e3.7
This happens normally when the folder in which test case is present is not a source folder, please check this post as well.
Hope that helps!
This can also happen if there is a problem with the groovy class. A few things to check:
1) Ensure that the class name exactly matches the filename (filename = MyTest.groovy)
package com.mypackage;
import groovy.util.GroovyTestCase;
class MyTest extends GroovyTestCase {}
2) Ensure that the package defined in the file matches the package the file is actually in.
In Eclipse you can do
Right click -> properties -> Java build path
Notice test folder is not available in sources. Add it.
Add folder -> Select test -> OK
Now rerun you unit test cases.
This happened to me, and I just restarted Eclipse (GGTS) and everything was fine again.
I had a spelling mistake which lead to that error message. My test class file name was named JUnit5Test.java (with upper U) and the class itself was named Junit5Test (with lower u).
I was using Spring Tool Suite 4 (4.8.0.RELEASE).
This also happened to me. But these tests are written in Groovy. The problem I encountered has to do with how the IDE (Eclipse Kepler, Java EE) first opens a Groovy project after executing "mvn eclipse:eclipse".
The Build Paths do not reference the Groovy source files correctly.
To resolve, I:
Right-click on the project, select "Build Path" > "Configure Build Path..."
Select "Source" tab
For test and src folders (.../src/main/groovy, and .../src/test/groovy)
make sure "**/*.groovy" is set as "Inclusion patterns", not "**/*.java"
Hope this saves time for someone.
Cheers!
I had the same error message when I head the test-class duplicated both in the main Java source folder and the testsrc folder. Removing the incorrectly placed one in the main Java source folder solved the problem for me.
2019 Update: This drove me crazy for days even with latest Eclipse and fresh installs (Mac, Grails 4, Gradle 5.1.1, Java 8). Some above examples led me to the solution.
My problem was more that the code I was testing included a mix of groovy and java src/main code. It gave me NoClassDefFound on the .groovy classes when I ran my Spec as JUnit.
Solution: I had to modify my Run/Debug Configuration to include build/classes/groovy/main. Then it worked. It's a little bit of a pain to remember to that for every new Configuration, but, it keeps me going. I hope it helps you.
Whenever you create a Junit test in eclipse, make sure your Junit test file is inside src/test/java folder.
I had a similar problem. Like others have already pointed out, it was about source folders. I had to change my source folder setup. There was an empty src-folder that disappeared after I right-clicked on it and selected 'remove from build path' from Build path menu. After that I right-clicked both java/src and java/test folders and chose Build path > Use as a source folder. And suddenly my tests were JUnited!
In similar situations I'd advice to remove all source folders from build path and add them again when you're sure you've got the right ones. Your source folders should be those with Java package structure under them. In case of proj/java/test/com/stackoverflow/main it's the 'test' folder.
This is what resolved for me (Eclipse Oxygen). I had already done what Robert suggested in the earlier post. I was still getting the error. When I went to edit the configuration for junit launch, I saw that the Test Class field just had the class name. I had to hit the Search button to the right. The Test Class field now had the complete name for the class
com.mycompany.mypackage.MyClass
With this I am able to run the JUnit. But I have to keep fixing this for every run.
Found another way to cause this message. The cause turned out to be an empty copy of MyTest.java under src/main/java, as well as the real one under src/test/java.
Think the empty file was a hangover from some refactoring and was oddly causing no compile errors either. Deleting it enabled the test to run again.