This request comes from a couple of STS issues
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?
Is my question too hard to answer?
As an alternative I guess STS Gradle plugin could try to use the dependency data (maven coordinates for jars) to implements its own conflict resolution.
I’d like to avoid that if possible since at best it duplicates Gradle functionality and at worst it might not behave the same if users customized how it works in their build scripts.
Any thoughts on this apreciated.
Kris
This is a pretty general problem with the IDE integration that also affects people that use the Eclipse plugin (in Gradle) to generate the Eclipse project files, and also people using IDEA.
I think what we want to do here is change the IDE mappings (that convert the Gradle model to the IDE model to send across the tooling API) so that they basically treat the runtime classpath of all IDE projects as a single dependency graph. What this means is that the same version of a given module will be used across all classpaths that require that module.
Given that the classpaths that Gradle uses and the classpaths that the IDE uses can potentially be different, we should have some way to let the user know when the classpaths are different. This isn’t really a new problem, but changing the conflict handling to apply across all IDE projects would possibly make this happen more often.
It would also be a good thing to be able to (optionally) apply this cross-project conflict resolution at the Gradle level, too.
My understanding of this issue is a bit ‘sketchy’ still.
However, an obervation made by user submitting the bug to STS was that when they run the project via gradle the runtime classpath doesn’t have a problem. When they run it via Eclipse/STS the conflict arises.
I beleave the reason for the conflict is that Eclipse computes a runtime classpath for project transitively based on the .classpath file. So the .classpath in effect works more like a compile time classpath to Eclipse and it has its own logic to compute the runtime classpath based on that.
Unfortunately Eclipse doesn’t understand about the maven coordinates of the jars and has no conflict resolution. All jars are considered ‘different’ rather than potentially being only different versions of the same thing.
I beleave with a bit of hacking / investigation I might be able to override how Eclipse computes the runtime classpath. Now… if I would be able to ask Gradle what it would be using for running the project then maybe we could just use that instead and the problem be solved?
It might be a bit more complicate than that but it seems it might lead to a solution.
Your idea of trying to resolve conflicts so that all projects in a mutli-project build agree on using the same version seems like it would work also. It would also be less work for me since it would require no hacking/exploring inside Eclipse to figure out how to override the runtime classpath it uses.
The big question is… is there anything we (you or I) can/should do in the near future to try and improve on the status quo?
Kris
Afterthought: Your proposed solution is suprior also in that it will fix issue accross all of these:
If you are committed to implementing that solution, then I can probably close the STS bugs and point to your issue ticket about that 
Are there any plans for implementing this? This is causing fairly serious problems for us.
Should I open a feature request for this? I’m one of those people that is having issues. We use eclipse here at work for webapps, and I’ve created gradle build files for our projects, but can’t get everyone else to use it until I get the eclipse integration fixed. Hence, we’re stuck on ant.
I’m curious if anyone has any tips on how they develop web apps quickly with gradle in an IDE without this issue coming up. I can’t imagine no one is doing it.
I’m guessing maven must have already implemented this, since their IDE plugins seem to grab the runtime set of jars correctly. ??
I’ve also tried to learn IntelliJ IDEA to see if there was a workaround for that. It seems I might be able to create a task that generates the artifact file using the gradleProject.configurations.runtime property. But seems eclipse works a lot differently so it seems there are no config files i could tweak to use the build in functionality. I guess maybe I could not use the eclipse gradle plugin, and do everything through the command line. Hmm… maybe that’s what people do.
The place to open feature requests is this forum (topic of type “idea”). I’ve promoted this topic to JIRA (GRADLE-2901). I don’t have any information on when it will be implemented.