SNAPSHOT dependency resolution problems

(steve) #1

I’ve searched these forums as well as SO. On these forums I found nothing that exactly matches the problem I am seeing, even though it seems like the most basic of SNAPSHOT resolution problems. On SO I only found (seemingly) out-of-date solutions that do not fix the problem. So I apologize up front if I missed something - please free to point me to the information I missed

All that said I am having trouble getting SNAPSHOT dependencies to be resolved properly. The generalized problem is that Gradle has trouble recognizing newer SNAPSHOT versions.

I have a pretty basic dependency:

ext { hibernateVersion = '5.3.0-SNAPSHOT' }

dependencies {
compile( “org.hibernate:hibernate-core:${hibernateVersion}” )
compile( “org.hibernate:hibernate-testing:${hibernateVersion}” ) {
transitive = false

When I publish new SNAPSHOTs of these Gradle will often ignore the newer ones. I’ve tried one consistent suggestion I found on SO:

configurations.all { // check for updates every build resolutionStrategy.cacheChangingModulesFor 0, 'seconds' }

ext {
hibernateVersion = ‘5.3.0-SNAPSHOT’

dependencies {
compile( “org.hibernate:hibernate-core:${hibernateVersion}” ) {
changing = true
compile( “org.hibernate:hibernate-testing:${hibernateVersion}” ) {
transitive = false
changing = true

However, even this does not work. So as an example, I perform a publish on hibernate-core:


But Gradle does not “see” this version, instead keeping the one it previously downloaded:


As you can see the versions are not the same. And to clarify, this repo makes these uploaded artifacts available immediately so there is no “latency” problem.

Interestingly, after 24 hours it does now see the newer version. I say 24 hours because AFAIK that is the Gradle default handling for SNAPSHOT dependencies, although all I can really say definitively is that it is after some “significant” amount of time" has passed.

So its essentially like Gradle either does not see these dependency/configuration changes or accept/honor them.

How do I fix this? Thanks in advance

(steve) #2

BTW, I fogot to mention - I have also tried deleting the local gradle cached version of the entire 5.3.0-SNAPSHOT directory to no avail… Grade simply downloads the older one again.

(steve) #3

So I guess I can assume SNAPSHOT dependencies really are not supported by Gradle, which is just a huge disappointment. And I consider Gradle not being able to disable the caching of these to be non-support. Very disappointing.

(Benjamin Muschko) #4

Hi Steve,

I tried to reproduce your issue but couldn’t. Please find my sample project here. For trying it out I downloaded and installed Artifactory OSS 5.6.2.

  1. In Artifactory set up a local Maven 2 repository. The “Maven Snapshot Version Behavior” is set to “Unique”, meaning it’s timestamp based.
  2. Navigate to producer directory. Upload a new snapshot version with ../gradlew uploadArchives.
  3. Navigate to consumer directory. Use the latest snapshot version by executing ../gradlew run. You should see the message rendered by the main method.
  4. Change the message rendered in the main method. Repeat 2. and 3. You should see the changed message.

Some comments about your code:

  • Dependencies with SNAPSHOT suffix in version are changing by default. You don’t need to add changing = true.
  • Where exactly do you apply resolutionStrategy.cacheChangingModulesFor? Maybe the setting is not applied somehow.
  • What repository product are you using? From the URL it seems like you are using Sonatype Nexus? If yes what settings are you using for your repository?

(steve) #5

Hey Benjamin, you can see the entire contents of the file here:

As for the repo, it is the JBoss Snapshot repo and yes it uses Nexus (beyond my control unfortunately). I have no idea what settings are used. What settings should I ask about?

(Benjamin Muschko) #6

I just tried out my sample project with Nexus OSS 3.6.2-01 as well and it works fine. In the settings of the repository I have the following under “Maven 2”:

Version policy: Snapshot
Layout policy: Strict

Maybe you can ask about the settings you have in place there.

Regarding your project: Can you try to trim down your build code to the basics to see if you can identify a specific issue. Please also remove the changing=true as it is not required. Apart from that nothing sticks out as an obvious issue. Could you please also provide the code that publishes the SNAPSHOT version?

(steve) #7

Thanks for the help Benjamin, I appreciate it.

The code is Hibernate. Specifically this branch: Check out that branch, cd into hibernate-core and run ../gradlew publish.

Here is what I see in the Nexus UI (I do not have “admin” access, this is just what I can see in the “Repositories” tab):

Format: maven2 Policy: Snapshot

It does not show any value for “Layout Policy”, but is that really impactful here?

(steve) #8

I will work on paring that build down. Can you at least confirm that I have the resolutionStrategy.cacheChangingModulesFor part correct?

I will remove changing=true, but considering that is the default, will that really have in impact?

(Benjamin Muschko) #9

That looks correct to me.

That shouldn’t matter. It will just set the property to true which should have that value anyway. I just want to remove any unnecessary build code to be able to easier identify the root cause.

I am not a Nexus expert unfortunately but I guess it shouldn’t matter for our use case. Just wanted to make sure that at least the version policy is set correctly.

Two more things I’d like to see:

  • Could you provide us with a build scan of a build that does not properly resolve the latest SNAPSHOT version?
  • Could you run your build with -d to see if we can find additional information on what going on under the covers during dependency resolution?

Regarding your publishing code:

  1. You are using the new Maven publishing plugin. My code used the “old” one. I am going to try out my sample project with the new plugin to see if there’s some issue.
  2. What’s the reason for having this code? I believe you don’t need that.
model {
    tasks.generatePomFileForMavenJavaPublication {
        destination = file( "$subProject.buildDir/generated-pom.xml" )

(steve) #10

IIUC you are asking why I need the model {..} block? If so, I don’t understand - I actually do not have that in my build. In fact I do not configure publishing at all, just let the defaults kick in

(Benjamin Muschko) #11

I was referring to this:

(steve) #12

At the time, I think it was needed - back when the new publishing had just been kinda-sorta released. Maybe that’s changed… not sure.

(Benjamin Muschko) #13

I just tried out my sample project with the Maven Publish plugin. Works as well. I’d need to see your logs/build scan. I’d also be interested in your build options e.g. configure-on-demand etc. (that would be part of the build scan if you can provide it).

On your Nexus repository you might also want to check that the latest version is set in maven-metadata.xml after you published a new SNAPSHOT version.

BTW: Did this ever work for you?

(steve) #14

No, I have not gotten it to work :frowning:

How should I configure the bvuildScan?

(Benjamin Muschko) #15

You can find the info here: Looks like you already apply the plugin here: and configure it here: You should get a link at the end of a build for the build scan that you can send us over.

(steve) #16

I mean specifically for :

recipe 'git-commit', baseUrl: ''

This is not part of the hibernate-orm tree, nor is it in any accessible repo

(Benjamin Muschko) #17

You can commented that out. It’s doesn’t really matter much for the analysis I think.

(steve) #18

Of course. As soon as i add scanning it starts working - it now downloads each new SNAPSHOT immediately after I publish it… ¯\(ツ)

(Benjamin Muschko) #19

There must be a reason for it. Maybe one of your plugins is messing with the cache settings for SNAPSHOT versions. Not sure. Let us know if you need further assistance.