Client Module dependencies breakage in Gradle 1.10


(David Huggins Daines) #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.+',
        'org.apache.lucene:lucene-core:3.5.+',
        'org.apache.lucene:lucene-analyzers:3.5.+',
        'com.yammer.metrics:metrics-core:2.0.+'
    }
}

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?


#2

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.


(Alexander Moosbrugger) #3

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: https://gist.github.com/samstgt/10927441

apply plugin: 'java'
  repositories {
 flatDir name: 'localRepository', dirs: "$projectDir/lib"
 }
    dependencies {
 compile module(":commons-email:1.+") {}
}

Replacing

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

with

compile ":commons-email:1.+"

results in a successful build. Gist containing debug output: https://gist.github.com/samstgt/10927863

Also replacing

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

with

compile module(":commons-email:1.2") {}

results in a successful build. Gist containing debug output: https://gist.github.com/samstgt/10928457

I hope this will help fixing the problem.


(René Groeschke) #4

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, rene


(Alexander Moosbrugger) #5

Tested with --refresh-dependencies and the problem still exists. https://gist.github.com/samstgt/10959231

If you need me to test something else, let me know.


(Alexander Moosbrugger) #6

Retested with 1.12-rc2 and problem still exists.

https://gist.github.com/samstgt/11259324


#7

Sorry about the delayed reply. To ensure this issue isn’t forgotten, I’ve raised GRADLE-3075 to track it.