Classpath generated by Eclipse includes dependent project's libraries avoiding gradle's conflict resolution

Help/Discuss Buildship
1

Hi,

We noticed that when running a main method or a unit test from eclipse on a project that is managed by BuildShip and includes dependencies on other projects, all of the dependent project’s libraries end up on the classpath. This bypasses gradle’s depedency conflict resolution and we end up with duplicate but differing jar versions on the classpath.

As an example, I have posted a simple project here : https://github.com/petehayes/eclipse-dep-test

There is a project ‘c’, that depends on both project ‘a’ and ‘b’. ‘a’ and ‘b’ both declare a dependency on log4j but not the same version. Project ‘c’ then depends on both of them. Inspecting the gradle dependencies, it properly only includes 1 version of the jar, and the ‘Project and External Dependencies’ container also shows just the 1 version of the jar. The problem is that if you right click and run the Main class via an eclipse run configuration, it will print out the classpath that eclipse gives it, showing both versions of the jar.

log4j-1.2.15.jar
mail-1.4.jar
activation-1.1.jar
log4j-1.2.14.jar

Is there some way to only get the gradle resolved libraries and ignore any of the dependent project’s libraries?

Thanks,
Pete

1 Like
2

I updated the sample project to include Maven based build settings. If you import into Eclipse as a Maven project and run the Main and the junit test, you will see that Maven does properly handle the classpath and only the maven resolved version of the jar is on the application and junit test classpath.

3

I also confirmed that Intellij IDEA properly handles the resolved classpath when running from the main application and junit tests from the IDE.

4

Hi Peter,

First of all, thank you for the elaborate explanation and the sample project, they made much easier to investigate the issue.

The problem is that Buildship sets the compile classpath for the projects but it doesn’t configure anything in terms of JDT runtime. As a result, the default runtime classpath is used when executing a main() method. Apparently, it includes all entries from classpath containers defined in referenced projects.

Fortunately there is a way to influence JDT runtime classpath calculation via this extension point. We plan to make use of this feature, especially because with that we can filter entries that are outside of the Gradle runtime classpath.

5

Here is the BugZilla entry you can follow for further updates on this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=481816

6

Thanks. This is a pretty major bug in my opinion. I don’t see a target version assigned - is this not a priority from your perspective? Is there a workaround that mitigates this?