[GRADLE-2652] IDEA and eclipse do not respect Gradle's conflict resolution Created: 25/Jan/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 15


 Description   

Consider following dependencies:

projectA -> projectB -> bar -> foo:1
projectA -> foo:2

Gradle's classpath for projectA:

foo:2(conflict resolution), projectB, bar

Effective IDEA / Eclipse classpath after generation with Gradle plugins for projectA:

projectB, (exported from projectB: bar, foo:1), foo:2

Problems:

1. ProjectA in IDEA uses foo:1 because coincidentally it is first on the classpath (the module dependencies are before jar dependencies). However, the ProjectA when ran in Gradle (e.g. test execution, running the app) uses foo:2 because of the conflict resolution. In other circumstances the problem might not show up because the version exported from a subproject might be the higher and might simply match the Gradle's conflict resolution.
2. Effectively there are 2 jars with conflicting versions on the same classpath in IDEA. E.g. ProjectA has both: foo:1 (exported from module dependency) and foo:2 (direct dependency) on the classpath.

Workarounds

(not that nice)

  • 'unexport' offending dependency in the IDE
  • reorder the dependencies in the IDE
  • some of the above can be probably automated with IDE whenMerged/withXml hooks
  • manually manage the conflict in the build scripts via forced versions

 Comments   
Comment by Gradle Forums [ 25/Jan/13 ]

Related discussion with IDEA guys:
[1]http://youtrack.jetbrains.com/issue/I...

Post on STS forum:
[2]http://forum.springsource.org/showthr...
----------------------------------------------------------------------------------------
[1] http://youtrack.jetbrains.com/issue/IDEA-99640
[2] http://forum.springsource.org/showthread.php?134326-Gradle-plugin-does-not-resolve-dependencies-using-default-strategy

Comment by Gradle Forums [ 25/Jan/13 ]

Thanks for reporting this problem!

I'd say it's a bug in Gradle. I would expect the generated IDEA configuration (with tooling api or with command line) to match the Gradle command line behavior (e.g. the actual classpath).

The scenario is not quite realistic because in reality one would have a consistent version of httpcomponents within the same multi-project. However, I realize that the scenario posted here is probably oversimplified for clarity.

I'll create a ticket for it in Jira and provide workarounds.

Comment by Andrey Myatlyuk [ 25/Jan/13 ]

I disagree about unrealistic scenario.

For example, in your multi-project build you have common project, which depends on library foo:1, and then you have business projects, which depend on common project. Let's say, you decide to update a version of foo to 2 - foo:2, would you rather do a staged roll-out, try project A, project B and project C? I would assume so. But with this bug, your project (A, B, C) will continue to use foo:1 and it will not work seamlessly without tweaking on user side.

Or you need specific functionality in foo:3, and your project is ready, but currently you cannot invest resources into other projects compatibility testing. Again, with current flow, it is impossible without tweaking. "One can't simply specify library version"

Maybe Gradle can report dependencies in a different order? So plugins will automatically place jars in front of projects on classpath. That will somehow help. Although it will continue to be an issue with multiple versions of jars on classpath...

Comment by Jonathan Aguin [ 12/Oct/15 ]

Is this still an issue?
I got a similar situation where a Compile dependency is being overwritten by a Test Compile by Gradle, but IDEA is using the Compile one ignoring the resolution.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 10/Feb/17 ]

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.

Generated at Wed Jun 30 12:27:45 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.