Launch config is missing JARs from the build.gradle


(Lucas Persson) #1

I am using spring boot and when I want to JUnit test from within Eclipse or launch the “main” class in my project then the class path isn’t what I expect.

When using spring boot I end up with about 75 jars in the path. The list of jars under “Project and External Dependencies” in the Package Explorer for my project looks as it should. I.e. all my needed JARs are listed.

However when I select my main class and do “Run As” then the generated class path used by Eclipse is lacking 5 JARs. I check the “Command line” in the Properties dialog for the launching in the Debug perspective.

I suspect that when Eclipse launches it will “ask” the Gradle plugin for the class path and I suppose that by some reason not all the JARs are returned from the Gradle plugin.
All other settings in the “Command line” looks OK.
When I re-order the dependencies in the build.grade for the project then there some other JARs that will be missing.

Alas I can’t repeat this issue consistently. Not all my projects have this issue.
But except for some differences in the dependencies there isn’t any differences.
4 out of 7 projects have this issue.

I have checked the Error log in Eclipse, it is empty.

I am using Eclipse Mars.2, Buildship
jdk1.8.0_77, OS X El Cap. Gradle 2.12 with the wrapper.

I have also tested with Buildship Same issue

(Stefan Oehme) #2

Hi Lucas,

Buildship currently doesn’t modify the “Run As” classpath in any way. So all jars that are on the Eclipse classpath should also be there when running. I can’t really give much further assistance without an example project that reproduces this issue. Do you think you can create one? :slight_smile:

Otherwise at least some screenshots of the classpath (both in the Project Explorer and in the Run Configuration tab) could help.


(Lucas Persson) #3

Hi Stefan

Yeah, I sort of understand your point. But I think it is more complicated.
The Gradle plugin is contributing a special classpath container to Eclipse which is backed by the build.gradle file. (At least it is how I think you have done it).
And when Eclipse launches a “run configuration” it will query the class patch container for all the JARs in it and its location on the file system. So I suspect it is here it goes wrong.

I will try to upload some screenshots. And also some sample project
Here is a snippet for the “command line”


I will try to fix a reproducible project. Hold on.


(Lucas Persson) #4

Here is how the Project looks in package explorer:

(Lucas Persson) #5

The “Run configuration” looks at it should, but then again it isn’t at that point the issue is. (at least that is my guess)

(Lucas Persson) #6


It turned out to be my own fault (of course).
I had added a dependent subproject directly in the .classpath file; e.g
<classpathentry combineaccessrules="false" kind="src" path="/common"/>
And also added this in the build.gradle;
compile project(':common').

But having
<classpathentry combineaccessrules="false" kind="src" path="/common"/>
isn’t needed. The Gradle plugin will fix that correctly anyway.

So sorry for the fuss.

(Stefan Oehme) #7

Thanks for verifying! Still curious how this would so thoroughly mess up Eclipse’s run behavior :slight_smile: