Introduction

The Gradle error "No matching variant found" after moving to Spring Boot Gradle plugin 3.0.0 usually points to a compatibility mismatch, not to a broken dependency declaration in isolation. In most cases, the build is asking for a plugin compiled for a newer Java or Gradle environment than the current project or IntelliJ import is providing.

Why Spring Boot 3 Triggers This

Spring Boot 3 raised baseline requirements significantly. The most important ones are:

• Java 17 or newer
• a compatible Gradle version, typically in the Gradle 7.5 plus range or newer

If your build still runs with Java 11, or IntelliJ imports the project with the wrong Gradle JVM, Gradle may fail variant selection because it cannot find a plugin artifact compatible with the requested environment.

Check the Gradle Wrapper First

The project wrapper must be new enough for Spring Boot 3.

# gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.6-bin.zip

If the wrapper is too old, upgrade it before debugging anything deeper.

./gradlew wrapper --gradle-version 7.6

Using the wrapper consistently also matters more than whatever Gradle version happens to be installed globally.

Check the Java Version Used by Gradle

Even if Java 17 is installed, IntelliJ may still import the project with an older Gradle JVM.

A compatible build file looks like this:

1plugins {
2    id 'java'
3    id 'org.springframework.boot' version '3.0.0'
4    id 'io.spring.dependency-management' version '1.1.0'
5}
6
7java {
8    toolchain {
9        languageVersion = JavaLanguageVersion.of(17)
10    }
11}

The toolchain helps document the intended Java level, but IntelliJ and Gradle still need to be configured to use a matching runtime during import and sync.

IntelliJ Can Be the Mismatch Point

The title mentions IntelliJ, and that matters because the IDE may use:

• the wrong Gradle JVM
• an old cached project model
• a different Gradle distribution than the wrapper

In IntelliJ, check:

• Gradle settings use "Gradle wrapper"
• Gradle JVM points to Java 17 or newer
• the project SDK is compatible with the build

If those are wrong, the command line build and the IDE import can behave differently even with the same build.gradle.

A Minimal Compatible Example

1plugins {
2    id 'java'
3    id 'org.springframework.boot' version '3.0.0'
4    id 'io.spring.dependency-management' version '1.1.0'
5}
6
7repositories {
8    mavenCentral()
9}
10
11dependencies {
12    implementation 'org.springframework.boot:spring-boot-starter-web'
13    testImplementation 'org.springframework.boot:spring-boot-starter-test'
14}
15
16tasks.named('test') {
17    useJUnitPlatform()
18}

If a project like this still fails with "No matching variant found," the next suspect is almost always the Gradle version or Java runtime rather than the dependency list itself.

Common Pitfalls

The biggest pitfall is upgrading the Spring Boot plugin without upgrading the Java runtime and Gradle wrapper alongside it. Spring Boot 3 is not a drop-in upgrade from older Boot lines.

Another common issue is letting IntelliJ use a bundled or previously selected Gradle JVM that does not match the CLI environment. That produces confusing situations where the project builds in one place and fails in the other.

Developers also waste time editing dependency coordinates when the variant error is actually about build-tool compatibility metadata, not about the application libraries.

Summary

• "No matching variant found" with Spring Boot plugin 3.0.0 usually means Java or Gradle compatibility is wrong.
• Spring Boot 3 expects Java 17 and a sufficiently new Gradle version.
• Use the Gradle wrapper and make sure IntelliJ imports the project with the wrapper and a Java 17 Gradle JVM.
• A minimal valid build.gradle is useful for isolating environment issues from dependency issues.
• Fix the toolchain mismatch first before changing application dependencies.