[GRADLE-2713] Dependency pulled remotely with same name, group and version as a multiproject subproject results in mysterious hard to fix error Created: 20/Mar/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.5-rc-2
Fix Version/s: None

Type: Bug
Reporter: Graeme Rocher Assignee: Unassigned
Resolution: Won't Fix Votes: 2


 Description   

This is a little hard to explain so I will try illustrate with an example. We have a subproject called "grails-datastore-gorm-mongo" that is defined in the same multiproject build as another subproject called "grails-datastore-gorm". The "grails-datastore-gorm-mongo" project declares a dependency on an external jar file not part of the multiproject build:

compile("org.grails:grails-plugin-domain-class:$grailsVersion")

This dependency transtively depends on "grails-datastore-gorm", which is as I said a project part of the multi project build. What happens is that Gradle actually downloads the published POM for the transitive dependency "grails-datastore-gorm", this is wrong because "grails-datastore-gorm" is part of the current multi-project build.

The result is a weird error such as


Execution failed for task ':grails-datastore-gorm-mongo:ideaModule'.
> Could not resolve all dependencies for configuration 'detachedConfiguration4'.
   > Module version group:org.grails, module:grails-datastore-gorm-mongo, version:1.2.0.RELEASE, configuration:detachedConfiguration4 declares a dependency on configuration 'signatures' which is not declared in the module descriptor for group:org.grails, module:grails-datastore-gorm, version:2.0.0.BUILD-SNAPSHOT

This is completely meaningless in describing the actual problem and had me digging into the bugs in the "signing" plugin. The solution for me was to go off and change the dependency declaration, for example:

compile("org.grails:grails-plugin-domain-class:$grailsVersion") {
    exclude group:"org.grails", module:"grails-datastore-gorm"
}
compile project(":grails-datastore-gorm")

Even though this is a solution, and allowed me to proceed this is wrong. I shouldn't have to exclude this transitive dependency as it is part of my current multi project build. I'm actually forced to provide wrong dependency configuration. The issue is compounded by the very bad error message which had me scratching my head for hours.



 Comments   
Comment by Luke Daley [ 11/Apr/13 ]

This would be very difficult to "handle" elegantly given our current publishing and project dependency model. It's likely would could improve the error message though of course.

We are working towards providing an elegant solution to this with our new publishing model.

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:29:27 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.