Failure to detect changing snapshot dependencies in m7 (works in m6)?

Old Forum
1

I seem to repeatedly get issues with updating snapshot dependencies when a new snapshot is available with the same version string. This used to work in m6. I am using the new syntax for setting the expiry dates:

configurations.classpath {
    resolutionStrategy {
      failOnVersionConflict()
      cacheDynamicVersionsFor 0, 'seconds'
      cacheChangingModulesFor 0, 'seconds'
    }
  }

this is for the ‘buildscript’ block in ‘settings.gradle’ but as far as I understand, that block should behave like any other dependency resolution block.

Is the “{ changing = true }” syntax still required/valid/recommended?

I have removed my entire gradle cache, removed all the .gradle dirs etc. Still no luck. Changing the micro version works as expected. This is running against an artifactory configuration which used to work fine in m6 and has not changed since I switched to m7.

Relevant debug log can be found here

Anyone else experienced issues with this?

Any help much appreciated.

2

Can you provide your ‘repositories { }’ and ‘dependencies { }’ sections, too?

3

sure can, this is from settings.gradle:

buildscript {
      repositories {
    maven {
      credentials.username artifactoryReader
      credentials.password artifactoryReaderPwd
      url "http://iteego.artifactoryonline.com/iteego/glasir"
    }
  }
    dependencies {
    classpath('com.iteego.glasir:glasir.build:1.0.37-SNAPSHOT')
    classpath('org.jfrog.buildinfo:build-info-extractor-gradle:2.0.7')
  }
    configurations.classpath {
    resolutionStrategy {
      failOnVersionConflict()
      cacheDynamicVersionsFor 0, 'seconds'
      cacheChangingModulesFor 0, 'seconds'
    }
  }
      configurations.classpath.each { file -> settings.classLoader.addURL(file.toURI().toURL()) }
}
4

As a side note, I checked the server xxxx.jar.sha1 file and actually downloaded the jar and those two match…and are different from the sha1 for the jar file linked to from the gradle cache into the binary file repository (in the gradle cache).

Also, just double checked by switching back to m6 and it immediately downloaded the updated snapshot, no other changes made to published artifacts, artifactory setup, project files, settings.gradle etc.

5

Hi,

recently I’ve upgraded to gradle m7, and have problems with fetching frequently changed snapshots.
I tried both:
1) Setting changing: true to the frequently changing dependencies:
compile group: ‘com.company’, name: ‘project’, version: 1.0.0-SNAPSHOT, changing: true
2) as suggested in the change log:
configurations.all {

resolutionStrategy.cacheChangingModulesFor 0, ‘seconds’
}

Still snapshots are not fetched, and I have to clean the cache every time the snapshot is question has been changed.

Do you have a solution to this problem?

Thanks!

This reply was created from a merged topic originally titled new snapshots are not fetched in m7.

6

Any thougths on this Adam? Any other data points we can provide to track this down?

7

Hi,

i am experiencing the same problem (publishing to an artifactory repository). my workaround is to set a timestamp property in the generated POM to force a changed SHA-1 for the .pom file. This seems to trigger a re-fetch of the artifacts.

pom.project {
         properties {
            'timestamp' String.valueOf(System.currentTimeMillis())
         }
      }
8

works for me, thanks!

9

Nice workaround! I can definitely use this for some of my projects. However, in the case which started this thread I’m not in control of the pom generation for the snapshot I need to download.

I have reverted to M6 until this issue gets addressed. Snapshot downloads seem to work fine in M6.

10

Any chance you guys can try a recent nightly build? http://gradle.org/nightly I’m not certain how this bug was introduced, but I believe it was probably fixed in this commit.

11

Now it works for me, but only with

configurations.all {

resolutionStrategy.cacheChangingModulesFor 0, ‘seconds’ }

But I would expect if a “changing” set to true for some snapshots, it is not necessary to provide the lines above. Otherwise, what’s the point in the “changing” property?

12

When you say “Now it works for me” do you mean you are using a nightly build?

In many cases, a “changing” module will change infrequently, so the default behaviour is to cache changing modules (and their artifacts) for 24 hours. Now that we use SHA1 keys to reduce unnecessary downloads, we might want to revisit this default.

13

Yes, I meant the nightly build. Thanks! So what is then the default behavior for modules for which “changing” is set to false?

14

These are cached indefinitely. We’re going to add a ‘rebuild’ feature that will force Gradle to check all cached artifacts are up-to-date. But currently if the module is not ‘changing’ we’ll never expire the cached entry.

15

I can verify that gradle-1.0-milestone-8-20120115000024+0100 seems to detect and download updated snapshot versions.

Any idea of what the time line for the m8 release is? Or if we could cherry pick this change into an updated m7? Not getting the latest snapshots has caused havoc in our dev process so we will be downgrading to m6 until this works.

16

btw, now I get warnings from gradle: “Forcing close on abandoned resource: Http GET Resource: https:///maven-metadata.xml”

Is it normal? This warning does not seem to affect me, though.

17

I can confirm that Gradle 1.0-milestone-8-20120115000024+0100 updates snapshots correctly- at least how i expect it to.

18

Yep you can ignore those. They won’t appear in M8 final.

19

We hope to have an M8 release candidate (snapshot) out this week or early next.