# Launcher classpath problem
**URL:** https://discuss.gradle.org/t/launcher-classpath-problem/30334
**Category:** Buildship
**Created:** [January 26, 2019, 11:23pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334 "2019-01-26T23:23:11Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [January 26, 2019, 11:23pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/1 "2019-01-26T23:23:11Z")
**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.
Any idea what’s going on?
Thanks.
Nat
---
### Author:  [@donat](https://discuss.gradle.org/u/donat)
#### Post date: [March 12, 2019, 10:01am UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/2 "2019-03-12T10:01:33Z")
If you provide a sample project then I’ll be able to effectively debug your problem.
Nonetheless, I have a [hunch](https://github.com/eclipse/buildship/pull/692) for the root cause. Does the problem appear in Buildship 2.2.2?
---
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [March 12, 2019, 1:41pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/3 "2019-03-12T13:41:30Z")
Yes, in fact I see now that upgrading from 2.2.1 to 2.2.2 introduces the broken behavior.
I hope this helps you confirm that your hunch is correct, because I’m not sure how easy it’d be for me to give you a simple sample.
Thanks.
Nat
---
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [March 25, 2019, 12:24pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/4 "2019-03-25T12:24:27Z")
Hi @donat ,
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.
Thanks.
Nat
---
### Author:  [@donat](https://discuss.gradle.org/u/donat)
#### Post date: [December 19, 2019, 1:44pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/5 "2019-12-19T13:44:34Z")
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.
---
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [January 14, 2020, 10:51pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/6 "2020-01-14T22:51:31Z")
@donat,
[For some reason [discuss.gradle.org](http://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.
Thanks.
Nat
---
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [October 6, 2020, 5:29pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/7 "2020-10-06T17:29:11Z")
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.
---
### Author:  [@onmishkin](https://discuss.gradle.org/u/onmishkin)
#### Post date: [October 16, 2020, 10:08pm UTC](https://discuss.gradle.org/t/launcher-classpath-problem/30334/8 "2020-10-16T22:08:31Z")
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](https://github.com/eclipse/buildship/issues/1034) with a repro case.