Using `latest.integration` for maven snapshot does not fetch the latest

Help/Discuss
1

I’m using the version catalog (Gradle 7.4.1) and I need to access snapshots libraries as they are instable at this time. But I would like to get the latest versions. For that I’m using latest.integration as documented on the gradle doc for dynamic versions.

[versions]
fireplace = "latest.integration"

[libraries]
fireplace-swing = { module = "io.github.bric3.fireplace:fireplace-swing", version.ref = "fireplace" }
fireplace-swing-animation = { module = "io.github.bric3.fireplace:fireplace-swing-animation", version.ref = "fireplace" }

[bundles]
fireplace = ["fireplace-swing", "fireplace-swing-animation"]

repositories {
    mavenCentral()
    maven("https://s01.oss.sonatype.org/content/repositories/snapshots")
}

dependencies {
    implementation(libs.bundles.fireplace) {
        isChanging = true
    }
}

configurations.all {
    resolutionStrategy.cacheChangingModulesFor(0, "seconds")
    resolutionStrategy.cacheDynamicVersionsFor(0, "seconds")
}

On the repository the maven-metadata.xml, indicates the following :


<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>io.github.bric3.fireplace</groupId>
  <artifactId>fireplace-swing</artifactId>
  <versioning>
    <latest>3a9439c-SNAPSHOT</latest>
    <versions>
      <version>publication-64115d5--SNAPSHOT</version>
      <version>pull-30-merge-e465fa4--SNAPSHOT</version>
      <version>e425109-SNAPSHOT</version>
      <version>cace2dd-SNAPSHOT</version>
      <version>4f06deb-SNAPSHOT</version>
      <version>6989e7e-SNAPSHOT</version>
      <version>d8346e0-SNAPSHOT</version>
      <version>12688e6-SNAPSHOT</version>
      <version>fe12c9b-SNAPSHOT</version>
      <version>5474f3a-SNAPSHOT</version>
      <version>89cb6fa-SNAPSHOT</version>
      <version>265b5fe-SNAPSHOT</version>
      <version>3a9439c-SNAPSHOT</version>
    </versions>
    <lastUpdated>20220321073023</lastUpdated>
  </versioning>
</metadata>

However even after a ./gradlew --refresh-dependencies, the latest snapshot is not used.

./gradlew dependencyInsight --dependency fireplace
Type-safe dependency accessors is an incubating feature.

> Task :dependencyInsight
io.github.bric3.fireplace:fireplace-swing:12688e6-SNAPSHOT:20220318.084249-1
   variant "apiElements" [
      org.gradle.category                = library
      org.gradle.dependency.bundling     = external
      org.gradle.jvm.version             = 11
      org.gradle.libraryelements         = jar (compatible with: classes)
      org.gradle.usage                   = java-api
      org.gradle.status                  = integration (not requested)

      Requested attributes not found in the selected variant:
         org.gradle.jvm.environment         = standard-jvm
         org.jetbrains.kotlin.platform.type = jvm
   ]

io.github.bric3.fireplace:fireplace-swing:latest.integration -> 12688e6-SNAPSHOT
\--- compileClasspath

io.github.bric3.fireplace:fireplace-swing-animation:5474f3a-SNAPSHOT:20220318.131601-1
   variant "apiElements" [
      org.gradle.category                = library
      org.gradle.dependency.bundling     = external
      org.gradle.jvm.version             = 11
      org.gradle.libraryelements         = jar (compatible with: classes)
      org.gradle.usage                   = java-api
      org.gradle.status                  = integration (not requested)

      Requested attributes not found in the selected variant:
         org.gradle.jvm.environment         = standard-jvm
         org.jetbrains.kotlin.platform.type = jvm
   ]

io.github.bric3.fireplace:fireplace-swing-animation:latest.integration -> 5474f3a-SNAPSHOT
\--- compileClasspath

I don’t think I’ve done something wrong. But maybe I missed something.

I’ve also tried to set the version as a +

- fireplace = "latest.integration"
+ fireplace = "+"

To get the latest version I must write the snapshot version manually

- fireplace = "latest.integration"
+ fireplace = "3a9439c-SNAPSHOT"

Could it because the snapshots have the commit it ?

2

Did you ever figure this out? We’re running into the exact same issue, our snapshot versions also include the commit hash. The only difference is Gradle fails to retrieve the latest version from our local Maven repo.

3

Nope. I ended up doing composite build because I could, consumed project was small enough, it was a gradle project as well, and it was buildable locally. And I declared this included build auto-discoverable in the settings.

4

Instead of latest.integration you can also just use +.
The point though is, that this either way not ordered by any date.
It is ordered by normal version-comparison semantics.
So for that to work the versions need to be ordered properly, for example like 0.0.1-build.1-3a9439c-SNAPSHOT and every publish must increase the build.1, then the commit id is just additional information that is not anymore relevant for version ordering.

As far as I know, you cannot change this behavior anyhow.

5

So Gradle does not read the the <latest> tag from the maven-metadata-local.xml file of the dependency?

6

No, “latest” is not really significant.
Just because a 1.0.1 hotfix was released last does not mean it is newer in terms of “latest dependency” than a 3.0.0.
I don’t think any other build tool goes for release time but always version ordering, just with slightly different ordering rules in some cases.

7

Maybe there could be some syntax added for “give me the version mentioned in the <latest> tag”, but you probably have to open a feature request and optimally a pull request for it if Gradle folks would accept it, as for such “ill-versioned” snapshot releases it might make sense to have the possibility..

What you could maybe do is download the file, extract the latest version and then use that version in the dependency declaration.

8

Appreciate the clarification. This seems more like a functionality gap with Gradle, as one of the main purposes of the metadata file is identifying which snapshot is the latest, as least that’s how Maven itself works. Fortunately ours is a relatively small project with infrequent updates to these dependencies, and we’ve worked around this issue by deleting the dependency and re-publishing it.