[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


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 {
flatDir(name: 'foo', dirs: "/path/to/directory/full/of/jars");

dependencies {
compile gradleApi()
compile localGroovy()

compile 'org.apache.uima:uimaj-core:2.3.+'

compile module('org.uimafit:uimafit:1.+') {
dependencies 'org.springframework:spring-core:3.+',

This worked fine in Gradle 1.9, but since Gradle 1.10, I get this error:

Could not resolve all dependencies for configuration ':runtime'.
> Could not download artifact 'org.uimafit:uimafit:1.+:uimafit.jar'
> Artifact 'org.uimafit:uimafit:1.+:uimafit.jar' not found.

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]
17:08:55.074 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] Listing all in .../uimafit-[revision].jar
17:08:55.080 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] using foo to list all in /redacted
17:08:55.087 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] found 147 urls
17:08:55.113 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] 1 matched .../uimafit-[revision].jar
17:08:55.117 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] Listing all in .../uimafit.jar
17:08:55.122 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ResourceVersionLister] revision token not defined in pattern .../uimafit.jar.
17:08:55.129 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver] Loading .../uimafit-1.2.0.jar

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
17:08:55.573 [DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver] Resource not reachable for org.uimafit#uimafit;1.!uimafit.jar: res=MissingResource: .../uimafit-1..jar

Any idea why?

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:

  • Check if this error persists with Gradle 1.11
  • Send the output when running the build with '--debug' (use Gist)

That would help a lot in tracking this down.

Comment by Gradle Forums [ 26/Apr/14 ]


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 {
flatDir name: 'localRepository', dirs: "$projectDir/lib"

dependencies {
compile module(":commons-email:1.+") {}

compile module(":commons-email:1.+") {}
compile ":commons-email:1.+"
results in a successful build. Gist containing debug output: [2]https://gist.github.com/samstgt/10927863

Also replacing
compile module(":commons-email:1.+") {}
compile module(":commons-email:1.2") {}
results in a successful build. Gist containing debug output: [3]https://gist.github.com/samstgt/10928457

I hope this will help fixing the problem.
[1] https://gist.github.com/samstgt/10927441
[2] https://gist.github.com/samstgt/10927863
[3] https://gist.github.com/samstgt/10928457

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


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.
[1] https://gist.github.com/samstgt/10959231

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:

  • 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:39:14 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.