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:

• STS-Gradle plugin
• Gradle eclipse pluing
• Idea tooling / Gradle plugin

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.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.