Summary
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.
Details
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.
I’m just following up to see if my observation about the breakage happening on upgrade from 2.2.1 to 2.2.2 is enough info for you to diagnose the problem and confirm your hunch, or whether I should try to boil the issue down to a sample project (which given the size and number of the projects that I’m seeing the problem in might not be a simple task). Or supply you with other info that might be helpful.
In recent versions we re-implemented the test classpath separation in Buildship. Can you please give it another go? If it doesn’t work, please provide a minimal example project that show the problem and I’ll continue investigating.
[For some reason discuss.gradle.org didn’t send me an email notification of your comment until a month after you posted it.]
Anyway, I updated to Eclipse 2019.12 and still see the problem and (as with the past several Eclipse releases) I had to downgrade to Buildship 2.2.1 to be able to get work done. (I assume the Buildship changes you mention are in fact in the version of Buildship that comes with Eclipse 2019.12.)
I also want to re-mention that the weirdness I mentioned earlier WRT the generated -classpath parameter (it includes “Eclipse”-style pathnames in addition to actual file system pathnames) continues to happen.
I’m happy to try to help however I can. I’m not sure I have the time right now to boil this down from the fairly complex environment where I’m seeing the problem into something I can send you though.
I’ve been ignoring this issue for nearly a year now, telling the devs on the project to just downgrade their Buildship to 2.2.1 whenever they take the latest Eclipse version but I think that “plan” is now at the end of the line because Buildship 2.2.1 doesn’t work with Eclipse 2020-09. (Eclipse 2020-09 requires Java 11 but Buildship 2.2.1 gets confused and throws an exception when it’s parsing the Java 11 version string.)
The classpath being generated for the target JVM is definitely wonky–it’s missing things that should be there and it contains invalid pathnames (Eclipse project pathnames rather than actual file system pathnames). Trying to distill my large source tree with many Gradle projects into a small sample case is going to be hard or impossible. Is there any kind of tracing or debugging I can do to figure out what’s going on? I’m happy to try to set up a dev environment to debug Buildship itself if that’s the best option.
I believe I’ve determined the problem is related to multi-project Gradle projects, some of which have multiple source sets. I filed https://github.com/eclipse/buildship/issues/1034 with a repro case.