Could not resolve org.springframework.boot:spring-boot-dependencies:2.2.6.RELEASE

First, here’s the error:

> Configure project :product-tests:java:tools:TestRunner
Not sharing system properties from Gradle process with JavaExec process
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':product-tests:java:build'.
> Could not resolve all task dependencies for configuration ':product-tests:java:detachedConfiguration1'.
   > Could not resolve org.springframework.boot:spring-boot-dependencies:2.2.6.RELEASE.
     Required by:
         project :product-tests:java > com.tableau.modules:tab-core-crypto:2.3.8
         project :product-tests:java > project :workgroup:src:silos:tsm:services:app-tabadmin-webapp > com.tableau.modules:tab-core-appconfig:2.2.0
      > Com.tableau.modules:tab-core-crypto:2.3.8 declares a dependency from configuration 'default' to configuration 'platform-runtime' which is not declared in the descriptor for org.springframework.boot:spring-boot-dependencies:2.2.6.RELEASE.

This is using Gradle 5.6.4. Digging into one of the “required by” dependencies, tab-core-crypto is built using spring-boot-dependencies as a platform:

dependencies {
    compile platform("org.springframework.boot:spring-boot-dependencies:${versions.spring_boot}")

In the ivy.xml file for the artifact, I see:

    <conf name="default" visibility="public" extends="jre8.rel"/>
    <conf name="jre8.rel" visibility="public"/>
    <conf name="runtimeElements" visibility="public"/>
    <conf name="sources" visibility="public"/>
    <artifact name="tab-core-crypto" type="jar" ext="jar" m:classifier="jre8.rel" xmlns:m=""/>
    <artifact name="tab-core-crypto" type="jar" ext="jar" conf="sources" m:classifier="sources" xmlns:m=""/>
    <dependency org="org.springframework.boot" name="spring-boot-dependencies" rev="2.2.6.RELEASE" conf="default-&gt;platform-runtime"/>
    <dependency org="" name="guava" rev="26.0-android" conf="default-&gt;runtime"/>
    <dependency org="org.slf4j" name="slf4j-api" rev="1.7.30" conf="default-&gt;runtime"/>
    <dependency org="commons-lang" name="commons-lang" rev="2.6" conf="default-&gt;runtime"/>
    <dependency org="commons-codec" name="commons-codec" rev="1.13" conf="default-&gt;runtime"/>
    <dependency org="commons-io" name="commons-io" rev="2.5" conf="default-&gt;runtime"/>

To make this even stranger, the error only hits sometimes, and we can’t yet figure out any rhyme or reason to when it will work and when it will fail. Does anybody have any idea what this error means and how to fix it?


1 Like

The problem faced here is the mixing of variant aware dependency resolution and legacy resolution.

In the project tab-core-crypto you use a platform dependency which means you opt-in the richer feature set of Gradle for dependency resolution. However it seems you did not opt-in publishing Gradle Module Metadata but instead relied only on Ivy.
However Gradle cannot express fully what happens then. The platform-runtime configuration does not exist for real in the Maven metadata. It is computed at runtime by Gradle.
But since there is an explicit configuration in the Ivy metadata, that computed metadata is not considered.

I would recommend upgrading Gradle as the publication of Gradle Module Metadata was not stable in 5.6, and making sure it is published and consumed. This would allow Gradle to use metadata fully explicit about what to consume.

As for why this only happens in some builds but not all, a reproducer would be needed with details on which tasks are invoked when it passes and when it fails.

1 Like

We started using platform as a Gradle built-in way to use versions from BOM files, without realizing the broader implications of it. The way our system is structured right now, it’s going to be a large effort to get to Gradle 6, and an even bigger one to not use Ivy for publishing. Is it possible to get the Module Metadata published in an Ivy repo? Or, would it be a moot point until we can also go to Gradle 6?

If we can’t use platform, what’s the suggested alternative? Go back to the Spring Boot dependency management plugin? Manually manage all of the dependency versions?

Unfortunately, the inconsistent results that we’ve seen are clearly environmental, and our build is such a beast that I can’t imagine how we’d identify and extract a small enough piece that we could hand it over for debugging. If we continue to hit this, I’ll see what I can do, though.

You can certainly publish Gradle Module Metadata with Gradke 5.6.

Follow the instructions in this blog post for this.
If available, GMM will be consumed transparently. This process can be disabled - see