I recently started noticing a problem running JUnit tests using launchers for Buildship-created projects in Eclipse 2018-12. In short, the test was throwing inexplicable ClassNotFoundException 's. By uninstalling Buildship 3.0.1 and then installing Buildship 2.2.1 I could make the problem stop happening. Once I upgraded back to 3.0.1 the problem reoccurred.
I used Eclipse’s new-ish “Show Command Line” feature in the Run Configurations dialog to determine that the -classpath argument is different depending on whether I’m using Buildship 3.0.1 vs. 2.2.1. The former is missing at least one of one project’s output folder.
I say “one of one project’s” because this project (call it the “core” project) has two source folders that contain Java source files and one source folder that contains non-Java “resources”. Each of these source folders has its own output folder. My other projects have just one Java source folder and one “resources” source folder.
It’s probably also worth my noting that one of the “core” project’s Java source folder contains generated Java code. The source code generation happens as part of a regular Gradle command invocation. The ClassNotFoundException. Until Buildship 3.0.2, at least, Buildship appears to have been capable of sorting this out. And it’s still seems to be capable WRT getting Eclipse projects that successfully compile. However, launching seems to have broken due to the incorrect -classpath parameter being generated.
I want to mention another anomaly that appears in the -classpath parameter, in both versions of Buildship: in addition to containing syntactically correct file system pathnames (i.e., of the form “/User/mishkin/foo/project1/bin/main”), the parameter also contains “Eclipse” pathnames–i.e., names of the form “/project1/main/bin”. The latter, being meaningless as file system pathnames, are ignored by the JRE. But it’s weird that they are there.
Any idea what’s going on?