This request comes from a couple of STS issues
https://issuetracker.springsource.com/browse/STS-3415 (poster’s point number 1)
In both instances there are problems with the way STS / Eclipse computes runtime classpaths for gradle projects. Simply put, Eclipse includes all transitive dependencies onto the runtime classpath. This is logical since in general the classes from transitive dependencies will be needed at runtime lest there not be ‘ClassNotFound’ type exceptions.
The problems arrise when users have complex project setups where multiple version of the same jar are transitively included in the classpath.
I beleave gradle has some mechanism to resolve such conflicts. (Though I’m not familiar with this mechanism).
The question is whether Eclipse / STS could somehow tap into the mechanism and obtain the runtime classpath for a project via tooling API, such that the conflicts are resolved the same way that gradle would.
Questions: 1) I am guessing at the moment (current tooling API) this is not possible? 2) If so, what can be done to make this possible?