Cannot update resolutionStrategy inside configurations block

Old Forum
1

Gradle 1.2 seems to have problem with changing modules in connection with Ivy resolver.

I have following configuration:

configurations {
sabreLibs {
    description = 'Sabre libraries'
    transitive = true
          resolutionStrategy {
      cacheChangingModulesFor 0, 'seconds'
    }
}
}

then library is defined as follows:

sabreLibs group: "com/sabre/airavailability/commons", name: "commons-utils", version: "5.5", changing: true

Unfortunately it seems when library is changed without changing version number, Gradle can not see this change. It still uses old version of library.

I noticed that using: gradle dependencies helps a bit: during dependency graph printing I can see that new ivy.xml is downloaded and then when invoking: gradle eclipseClasspath I can see that new version of jar is downloaded.

Is it a known bug? How can I clean cache for temporal solution?

2

Should I report a bug?

3

How is your resolver declared? This functionality is working for many people, so I presume there is something about your particular setup that is causing you issues.

4

Hello!

Sorry for late answer - I have had vacation. Below you can find my definition of ivy resolver.

As I said above this configuration works very well, EXCEPT of situation when module was changed, without changing module version. In such a case module is not retrieved from repository. (We don’t use *SNAPSHOT.jar convention.)

It would be nice to resolve this issue - I am trying to convince my team to start using Gradle (as it is really wonderful tool.), but it’s more difficult when having problems with changing modules. It’s quite common practice here to update module without changing its version.

repositories {
  ivy {
    url "http://******/content/repositories/releases/"
      credentials {
      username '*****'
      password '*****'
    }
      layout 'pattern', {
      artifact "[organisation]/[module]/[revision]/[artifact](-[classifier]).[ext]"
      ivy "[organisation]/[module]/[revision]/ivy.xml"
    }
  }
    maven { url "http://****/content/repositories/central" }
}
5

Unfortunately it seems when library is changed without changing version number, Gradle can not see this change. It still uses old version of library.

Inoticed that using:

gradle dependencies

helps a bit: during dependency graph printing I can see that new ivy.xml is downloaded and then when invoking:

gradle eclipseClasspath

I can see that new version of jar is downloaded.

So you’re saying that when you execute ‘eclipseClasspath’, Gradle does detect & download the changed jar file? If so, this means that dependency resolution is working as expected.

In what scenario do you find that Gradle does not detect & download the changed jar file?

A simple test would be to use a task that resolves the configuration and copies all of the jar files into a separate directory. Can you test if the changed jar is detected in this case?

task copyToLib(type: Copy) {
    into "$buildDir/output/lib"
    from configurations.sableLibs
}

Finally, running the build with ‘–info’ gives extra details about dependency resolution.

6

When I changed module in repository and issue:

gradle eclipseClasspath

Gradle does not download new version of module. Only issuing following commands one after one triggers downloading new version of module:

gradle dependencies
gradle eclipseClasspath

It’s also not only problem with ‘gradle eclipseClasspath’ command, as builds on CI server were not working because of the same problem.

I have rechecked everything once again to be sure. It’s 100% reproducible - nothing is downloaded without issuing first ‘gradle dependencies’. I was looking at Gradle cache directory and comparing SHA1 hashes.

7

Please add the simple ‘copyToLibs’ task that I outlined above and post the output of execution, running as:

gradle --debug copyToLibs

If that is successfully downloading a changed module, please then post the output of:

gradle --debug eclipseClasspath

The output of ‘gradle -v’ may also prove helpful. Use a pastebin service like Gist to post your log output.

It is possible that there is something about the eclipseClasspath task that means it is not forcing dependency resolution. But it’s odd that this hasn’t been reported by other users.

8

I have made few, more systematic than earlier, tests. You can find results here: https://gist.github.com/4451665

Tests were done one after one - please notice information about order in sequence at the beginning of file. You can find there also information about all changes between tests.

Please remember also that problem is not only connected with eclipseClasspath task, but also with other tasks. For example I have attached also compileJava task logs.

copyToLibs task was executed twice - first time with cleaned cache, and second time without cleaning cache.

9

These lines indicate the problem:

11:33:54.436 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleVersionRepository] Found cached version of changing module 'com/sabre/airavailability/commons#commons-utils;5.5' in 'ivy'
11:33:54.436 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleVersionRepository] Using cached module metadata for module 'com/sabre/airavailability/commons#commons-utils;5.5' in 'ivy'

If the resolutionStrategy is being correctly set, then you should see lines something like:

10:45:24.540 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleVersionRepository] Cached meta-data for changing module is expired: will perform fresh resolve of 'org.cachepolicy.zoo#zoo;1.0' in 'ivy'

So it appears that there is a problem with your setting of the ‘cacheChangingModulesFor’ property. While the syntax you provided should work, can you retry with

configurations.all {
     cacheChangingModulesFor 0, 'seconds'
}

If this doesn’t work, can you please provide a self-contained sample demonstrating the issue? All of my testing indicates that this functionality works correctly for Gradle v1.2 and v1.3.

10

Indeed, when I have added

configurations.all {
  resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}

dependency resolution works correctly and new jars are downloaded as expected.

It seems that this is a problem with particular syntax which I have used. But this syntax should work, as you have already said, so I think it is plainly bug.

11

Can you test with the latest Gradle nightly build? There has been a bug fixed with ResolutionStrategy that may address your issue.

If this doesn’t work, it would be great if you could provide a self-contained sample that we can run to reproduce this issue. That would go a long way to helping us fix it. Thanks!

12

Also might be worth trying:

configurations {
sabreLibs {
    description = 'Sabre libraries'
    transitive = true
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}
}
13

I have tested both below configurations and they don’t work with latest nightly (gradle-1.4-20130107230014+0000-bin.zip):

configurations {
  sabreLibs {
    description = 'Sabre libraries'
    transitive = true
    resolutionStrategy {
      cacheChangingModulesFor 0, 'seconds'
    }
  }
}

configurations {
  sabreLibs {
    description = 'Sabre libraries'
    transitive = true
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
  }
}

What you mean saying “self-contained sample”? I think that it’s quite clear from my description what my configuration is?

I can just add that build files are separated into two: 1. common.gradle

  • common part for few projects 2. build.gradle - part specific for project, which defines dependencies but it probably doesn’t matter.
14

Thanks for testing with the latest nightly. I’ve added this as GRADLE-2619.

A self-contained sample would be a single build file or perhaps a public GitHub repository which can be run to demonstrate this problem. It’s not essential, but it would help us to reproduce the problem, which in turn can help us to implement a fix.

Our development resources are limited, and being an open source project we rely on contributors like yourself to help us make Gradle better.

15

It seems that similar problem is with e.g. failOnVersionConflict()

Adding it to specific configuration doesn’t work. This case is probably more important than with ‘cacheChangingModulesFor’.