I've been using Eclipse 2019-12 since the day it was released. I have a bunch of different related projects that are all SpringBoot Java Maven projects, which were imported from my local git repositories.
In general, all of these work perfectly fine.
Yesterday, I discovered that I couldn't run unit tests in Eclipse for one particular project. This project had been in my workspace for quite a while, and I do things with it almost every day, including running unit tests. What I saw yesterday is that all my attempts failed because it couldn't find the test class file. Other similar projects had no problem with this. I viewed the settings for the project, and there was nothing unexpected. The src/test/java directory was a source directory, and I could use "Open Type" to open the test class. I tried doing "Maven Update". No change. Running "mvn package" from the shell works fine, and I can clearly see that it executes all the unit tests.
I tried deleting the project and reimporting from git. No change.
I then tried deleting the project again, and then manually deleted the .project, .classpath, and .settings files and folder, and then reimporting from git. This made it worse. Initially, it didn't appear to know it was even a Java project.
I then deleted the project again and edited the .project file from another editor. I compared it to to one of the other .project files. It only had the "maven2Builder", and didn't have the "javabuilder" or "springbootbuilder". It also only had the "maven2nature", and didn't have the "javanature" or "groovyNature". I manually copied those elements from the other .project file and reimported the project.
At this point, it knew it was a Java project, but it only added the root "src" directory as the only source folder, instead of src/main/java, src/test/java, and others. I also noted that it still didn't have a .classpath file. So, I deleted the project again and created the .classpath file with an external editor. I copied in the .classpath file from a related project. The structure of the two projects were identical, so this barely required any changes (the other project had one additional source folder that this project didn't have, so I deleted that entry). I then reimported the project again.
The project now "looks" normal in the package explorer. However, I STILL cannot execute unit tests in this class. I have come full circle. I can open the test class with "Open Type", but executing it fails with a ClassNotFoundException in the console.
If I search for the particular test class file in the shell, I find it in the expected locations in both "bin" and "target/test-classes", in the correct package directory.
I looked in the Eclipse error log, and there was nothing significant there.
Curiously, I'm seeing no issue with "Run/Debug As ... Spring Boot App". This finds all of the required class files and starts up fine. I just can't run unit tests.
I don't know what else to try.
Update:
As unit tests in other projects are working fine, I tried comparing aspects of one working unit test with one in the bad project. I first looked at the run configurations, and I stepped through each tab, going back and forth between the two run configurations, and the only difference I saw was the name of the project, so I found nothing of interest there.
I then looked for the working class file in the shell in the working project, and what was curious is that I did NOT find it in the "bin" tree. In fact, the working project didn't even have a "bin" directory. I then verified that the project properties didn't even refer to a "bin" directory, including any of the "output folders", in both projects.
So, I then deleted the project again, and then deleted the "bin" directory from the shell, and reimported the project. Unfortunately, still no change in the overall symptom. It still gets the ClassNotFoundException trying to run the test class.
Update:
I'm running on Windows 10, and I decided to try using SysInternals ProcMon to monitor system calls (like Linux (s/d)trace) while I attempt to run the test. I filtered for the name of the test class. The result showed one possible clue.
This is a somewhat elided image of the list of events that I saw in procmon when I ran the unit test:
I don't know why the operation is "Create File", but I note that the folder path referenced here is "target/classes", not "target/test-classes". Despite the fact that the class file is in the "target/test-classes" tree, I saw no system call that referenced that directory, only "target/classes".
Update:
I tried going through the steps of manually creating a JUnit run configuration. When I first selected the project that is working and then clicking "Search" on the "Test Class" field, it brought up a dialog with many classes in the "Matching Items" list. When I instead selected the project that is having this problem and then clicking the same "Search" button, the list of "Matching Items" in the dialog was empty. I'm not sure what to do with that fact.
Update:
I decided to try adding more verbosity when it tries to run the unit test class, both in the working project and the NOT working project. In both run configurations, I added "Xdiag -XshowSettings".
When I compared the results, I found that both showed a "java.class.path" value that included all the expected directories, being "target\test-classes" and "target\classes", even the one that is NOT working. However, note the very subtle difference:
Working:
java.class.path = C:\Users\<myuid>\git\futurebillestimatorms\target\test-classes
C:\Users\<myuid>\git\futurebillestimatorms\target\classes
NOT working:
java.class.path = "C:\Users\<myuid>\git\checkoutms\target\test-classes
C:\Users\<myuid>\git\checkoutms\target\classes
Note the one character difference, the double quote at the beginning of the value in the NOT working sample. There is a matching double quote at the end of the long list of classpath entries. The one that is working does not have those double quotes. The double quotes around the java.class.path value are the only double quotes anywhere in the output.
Update:
Ok. I have a workaround. This is an issue in Windows with the 2019-12 release. This is the bug report that describes the problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=558495 .
The simplest hack for me at this point is to check the "Use temporary jar" checkbox in the Run Configuration.