How to automatically resolve the latest consumer stub version in Spring Cloud Contract (provider-side)?

[Awakuruf]

Background

I'm running provider-side contract verification in a Spring Cloud Contract (SCC) setup where the consumer publishes stub JARs to Artifactory. The provider's pom.xml has a property that pins the consumer stub version:

<consumer-service.contract.version>3.1.15-SNAPSHOT</consumer-service.contract.version>

This version is passed to the SCC Maven plugin as the contractDependency version so the provider pulls the correct stub JAR during generateTests.

The Problem

Pinning a static version creates a silent false-positive problem:

• The consumer continuously publishes new SNAPSHOTs (3.1.15-SNAPSHOT, 3.1.16-SNAPSHOT, etc.) with updated contracts
• The provider's pom.xml is never updated to match
• Provider CI keeps verifying against an old stub — breaking changes in the consumer's contracts go completely undetected
• All tests pass, but the provider and consumer are actually out of sync

This defeats the purpose of consumer-driven contract testing.

What I tried

Using + or leaving the version blank in the SCC plugin configuration — both result in:

No stubs or contracts were found for [com:consumer-service:+:stubs]

SCC's LATEST_VERSION (+) doesn't seem to resolve correctly against our internal Artifactory instance for SNAPSHOT artifacts.

Question

Is there a built-in or idiomatic way in Spring Cloud Contract to always resolve the latest available stub version from a remote Artifactory repository without having to manually maintain a version pin or use an external script?

Specifically:

1. Is there a supported version syntax (similar to Maven's LATEST or RELEASE) that SCC's contractDependency resolution actually honours against Artifactory SNAPSHOT repos?
2. Is there a plugin configuration option (e.g., snapshotCheckSkip, updateSnapshots, or resolver settings) that would force re-resolution to the latest SNAPSHOT on every build?
3. Or is a pre-build metadata query (like my shell script approach) the accepted pattern for this use case?

Any guidance appreciated.

[Awakuruf]

Sorry to ask you again so many times @marcingrzejszczak
But this should be the last time I ask...

[marcingrzejszczak]

+, LATEST etc. should work because under the hood we're using aether. I'm surprised that it doesn't work - Can you create a reproducer please?

[Awakuruf]

@marcingrzejszczak Thanks for the response. Here is the reproducer information.

Environment:

• Maven version: 3.6.3
  ⁠- Spring Cloud Contract Maven Plugin: 4.0.7 (also tested 4.1.0, 4.2.0, 4.3.0 — all produce the same result)
• ⁠Java: 17
• Artifactory SNAPSHOT repository: [http://test-artifacts/artifactory/snapshots (https://artifacts.int/artifactory/snapshots)
• ⁠Available stub artifact: com:consumer-service:jar:stubs with multiple -SNAPSHOT versions published:

Reproducer:
In pom.xml, configure the plugin with no version (or +) as suggested:

<plugin>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-contract-maven-plugin</artifactId>
  <version>4.0.7</version>
  <extensions>true</extensions>
  <configuration>
    <contractsMode>REMOTE</contractsMode>
    <contractDependency>
      <groupId>com</groupId>
      <artifactId>consumer-service</artifactId>
      <!-- No version set, expecting LATEST resolution per your suggestion -->
      <classifier>stubs</classifier>
    </contractDependency>
    <contractsRepositoryUrl>[https://artifactory/snapshots</contractsRepositoryUrl>](https://artifactory/snapshots%3C/contractsRepositoryUrl%3E)
    <contractsPath>/contracts/provider</contractsPath>
    <failOnNoContracts>true</failOnNoContracts>
  </configuration>
</plugin>

Command run:
mvn spring-cloud-contract:generateTests

Observed error (with no version set):
[ERROR] Stub Downloader [org.springframework.cloud.contract.stubrunner.AetherStubDownloader] failed to find an entry for [com.consumer-service:+:stubs]. Will proceed to the next one. No matching stubs or contracts were found

Observed error (with + explicitly set):
[ERROR] Stub Downloader [org.springframework.cloud.contract.stubrunner.AetherStubDownloader] failed to find an entry for [com.consumer-service:+:stubs]. Will proceed to the next one. No matching stubs or contracts were found and the switch to fail on no stubs was set.

The plugin resolves the version string to + but then fails to find any artifact with that version string. It does not appear to be treating + as "latest" via Aether, it seems to be passing the literal string + as the version coordinate to the resolver, rather than using Aether's version range or latest resolution.

What works: Setting an explicit version like 3.1.15-SNAPSHOT resolves and downloads the artifact correctly from the same Artifactory SNAPSHOT repository.

Question: Is there a specific Aether version range syntax that the plugin supports? For example, should it be [3.0.0,) (open-ended range)? Or is LATEST/+ only supported for a specific repository layout (releases vs. snapshots)? Our artifacts are all -SNAPSHOT versions in a SNAPSHOT repository.

[Awakuruf]

@marcingrzejszczak Any luck with the above reproducer?

[marcingrzejszczak]

I asked my friend Claude to summarize my reproducers:

Investigation Summary for gh-2447

We tested the + (latest version) resolution extensively across multiple repository types to reproduce this issue.

What we tested:

1. Local file-based Maven repository (file://) — Using the existing test fixture with contractsMode=REMOTE, contractDependency with no version (defaults to +), and contractsRepositoryUrl pointing to a
   file:// repo. The + resolves correctly via the shaded Aether's version range (,] against maven-metadata.xml.
2. Spring Boot HTTP server mimicking Nexus/Artifactory — We stood up an HTTP server serving the exact same metadata format that Sonatype Nexus OSS 3.x produces, including timestamped snapshot filenames
   (contracts-0.0.1-20260315.130415-1.jar) and proper / elements in maven-metadata.xml. The + resolution works correctly.
3. Real Sonatype Nexus OSS 3.72.0 — We deployed a SNAPSHOT stub jar to a real Nexus instance using mvn deploy:deploy-file, which generates proper maven-metadata.xml automatically. The + resolution works
   correctly.
4. Real JFrog Artifactory OSS 5.x — We deployed a SNAPSHOT stub jar to a real Artifactory instance using mvn deploy:deploy-file, which generates proper maven-metadata.xml. Then ran
   MavenContractsDownloader with version="+" against http://localhost:8081/artifactory/example-repo-local/. Both + and empty version (which defaults to +) resolved correctly.

How the resolution works internally:

• MavenContractsDownloader.stubConfiguration() converts blank/null version to "+"
• AetherStubDownloader.getVersion() detects "+" and converts it to the Maven version range "(,]"
• resolveHighestArtifactVersion() uses Aether's VersionRangeRequest to query maven-metadata.xml from the remote repo
• The highest version is selected and the artifact is downloaded

All tests pass across all four repository types. We could not reproduce the failure described in the issue.

Could you provide:

1. The maven-metadata.xml that your Artifactory serves at /com/consumer-service/maven-metadata.xml — you can fetch it with curl -u user:pass
2. Is this a hosted (local) repo in Artifactory, or a virtual/remote repo?
3. The full Maven debug output: mvn spring-cloud-contract:generateTests -X 2>&1 | grep -A5 "AetherStubDownloader|version range|Resolved version"
4. Your Artifactory version

This will help us understand if Artifactory is serving metadata in a non-standard format or if there's an authentication/routing issue specific to your setup.