Gradle does not check SNAPSHOT timestamps across repos

Old Forum Archive Bugs
1

I reproduced this issue with two projects:

  • a gradle project that publishes a JAR in Maven with name -SNAPSHOT
  • a gradle project that depends on that JAR

The consumer has as config
repositories {
mavenLocal()
maven {
url “http://nexus.company.eu:8081/nexus/content/groups/repo/”
}
}

Gradle works as expected when I publish the snapshot and then retrieve it. He will download it and put it in .gradle caches, and will get a newer published file with same name (if I use the no caching options, or remove the cached file)
When I however build and install the first project, so that it gets installed in my local Maven repo (at expected place in .m2/repository) things go bad.

Every Gradle run will then resolve that SNAPSHOT in local repo, whether or not a newer SNAPSHOT is in the remote nexus repo. He will not put it in .gradle caches, he will simply keep retrieving it from local maven repo unless I delete the artifact or pom file (deleting maven-metadata of the artifact has no effect).

Is this a bug, or feature? Our use case is to always use the latest SNAPSHOT, regardless of the repo. This ensures that you can do a local fix/build/install and test it, and avoids you using outdated dependencies after CI has published a new one to remote.

If you need code to reproduce I will be happy to share. PS: I have no custom maven settings.xml in this reproduction

2

This is a known issue GRADLE-2257. Right now we stop looking at the first repository that contains the requested SNAPSHOT version. this means you’ll either have to a) rebuild and install latest to Maven local b) delete the old artifact from Maven local or c) reorder your repositories (which likely means it’ll never be resolved from Maven local).

3

Hi Mark, thanks for the swift reply. My Googling did not find this issue, but it indeed describes it fully. I would suggest that you add a bit of documentation to how Gradle handles Maven snapshots, as the Gradle docs do some explaining, but it gets confusing when mixing this with ‘dynamic’ versions and for multiple repo’s.

Sadly this does not solve our issue, as these work-arounds are not transparant, the user will always need to remember to clean Maven local cache himself, or to provide a flag to avoid local Maven usage when desired. This is hard to remember, snapshots may be built weeks ago and for many projects.

I am afraid we will have to avoid local repo completely, and only enable it when the user explicitly asks because he bult a local maven project to be used as dependency. That of course will be slower, as local Maven repo is a lot faster than remote for snapshots. But I also guess that’s why you don’t do multiple repo searches in first place on changing libs. The speed increase from porting Maven to Gradle is huge, but we do face caveats in resolving ldependencies ike this :slight_smile:

4

This is the issue. In any case, to get this to work we’ll have to go out and check every repository in order to determine what is “latest”. Current behavior is a performance optimization but it isn’t strictly correct (in that it doesn’t behave like Maven).

1 Like