Should I report a bug?

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.

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

}

> 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.

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.

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.

I have made few, more systematic than earlier, tests. You can find results here:
[1]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.
----------------------------------------------------------------------------------------
[1] https://gist.github.com/4451665

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.

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.

Can you test with the latest [Gradle nightly build]([1]http://www.gradle.org/nightly)? 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!
----------------------------------------------------------------------------------------
[1] http://www.gradle.org/nightly

Also might be worth trying:

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

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.

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!

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.