Affects Version/s: None
Fix Version/s: None
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
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.
(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