[GRADLE-3075] Client Module dependencies breakage in Gradle 1.10 Created: 26/Apr/14 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: | 1 |
Description |
For historical reasons I unfortunately need to use a flatDir repository pointing to a directory full of random jar files checked into SVN. So, I have a buildSrc/build.gradle that looks like this: repositories { dependencies { compile 'org.apache.uima:uimaj-core:2.3.+' compile module('org.uimafit:uimafit:1.+') { This worked fine in Gradle 1.9, but since Gradle 1.10, I get this error: Could not resolve all dependencies for configuration ':runtime'. When I look in the debug output, I see that it is initially finding the jar just fine: 17:08:55.067 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.UserResolverChain] Attempting to resolve module 'org.uimafit:uimafit:1.+' using repositories [foo] But then after visiting all the transitive dependencies, it tries to find it again and fails: 17:08:55.573 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver] Loading .../uimafit-1.+.jar Any idea why? |
Comments |
Comment by Gradle Forums [ 26/Apr/14 ] |
Hi David. I'm currently investigating a similar issue, and this definitely sounds like a bug. Can you please:
That would help a lot in tracking this down. |
Comment by Gradle Forums [ 26/Apr/14 ] |
Hi, I have the same issue since Gradle 1.10. I tested today with the new 1.12-RC1 and it still exists. In my case it always occurs if I use ClientModule in combination with '1.+' version syntax. The following build.gradle file will run into this issue (the project contains the file dependency lib/commons-email-1.2.jar). Gist containing debug output: [1]https://gist.github.com/samstgt/10927441 apply plugin: 'java' repositories { dependencies { Replacing Also replacing I hope this will help fixing the problem. |
Comment by Gradle Forums [ 26/Apr/14 ] |
Thanks for creating this simple reproducable sample. Does the problem still exists when running with --refresh-dependencies. I'll try to reproduce this on my local box later and come back to you cheers, |
Comment by Gradle Forums [ 26/Apr/14 ] |
Tested with --refresh-dependencies and the problem still exists. If you need me to test something else, let me know. |
Comment by Gradle Forums [ 26/Apr/14 ] |
Retested with 1.12-rc2 and problem still exists. [1]https://gist.github.com/samstgt/11259324 |
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:
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. |