IDEA and eclipse do not respect Gradle's conflict resolution

Details

  • Type: Bug Bug
  • Status: Open Open
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None

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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Gradle Forums added a comment -

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

Show
Gradle Forums added a comment - 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
Hide
Permalink
Gradle Forums added a comment -

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.

Show
Gradle Forums added a comment - 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.
Hide
Permalink
Andrey Myatlyuk added a comment -

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...

Show
Andrey Myatlyuk added a comment - 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...

People

  • Assignee:
    Unassigned
    Reporter:
    Gradle Forums
Vote (2)
Watch (5)

Dates

  • Created:
    Updated: