Introduction

When a build says spring-boot-starter-web:2.3.0.RELEASE cannot be found, the artifact itself is usually not the real problem. The usual causes are repository misconfiguration, an incorrect dependency declaration, or version management that bypasses Spring Boot's normal parent or plugin setup. The fastest fix is to simplify the build so Spring Boot manages its starter versions for you.

First Check the Dependency Coordinates

The actual Maven coordinates should look like this:

1<dependency>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-web</artifactId>
4</dependency>

If you are already using the Spring Boot parent or BOM, you normally should not hardcode the starter version here. Spring Boot manages compatible versions across the stack.

A common bad pattern is manually forcing one starter version while the rest of the build is managed differently.

Maven: Prefer the Spring Boot Parent

A clean Maven setup looks like this:

1<parent>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-starter-parent</artifactId>
4    <version>2.3.0.RELEASE</version>
5    <relativePath/>
6</parent>
7
8<dependencies>
9    <dependency>
10        <groupId>org.springframework.boot</groupId>
11        <artifactId>spring-boot-starter-web</artifactId>
12    </dependency>
13</dependencies>

With this structure, the starter version is inherited correctly and Maven resolves dependencies from the managed BOM.

If you are not using the parent, use dependencyManagement with the Spring Boot BOM instead.

Gradle: Use the Plugin and mavenCentral()

For Gradle, the normal setup is also straightforward:

1plugins {
2    id 'org.springframework.boot' version '2.3.0.RELEASE'
3    id 'io.spring.dependency-management' version '1.0.9.RELEASE'
4    id 'java'
5}
6
7repositories {
8    mavenCentral()
9}
10
11dependencies {
12    implementation 'org.springframework.boot:spring-boot-starter-web'
13}

Again, avoid pinning a separate starter version unless you have a very specific reason.

Repository Configuration Still Matters

Even valid coordinates fail if the build cannot reach the repository. For most Spring Boot dependencies, mavenCentral() is enough today.

Maven example:

1<repositories>
2    <repository>
3        <id>central</id>
4        <url>https://repo.maven.apache.org/maven2</url>
5    </repository>
6</repositories>

In many corporate environments, the real problem is an internal Nexus or Artifactory mirror that is stale or blocked, not Maven Central itself.

Clear a Bad Cache When the Coordinates Are Correct

If the dependency line is correct and the repository is correct, a cached failed lookup may still keep the build broken.

Maven:

rm -rf ~/.m2/repository/org/springframework/boot
mvn -U clean package

Gradle:

./gradlew build --refresh-dependencies

Do this only after verifying the declaration. Refreshing a bad build file does not fix the root cause.

Watch for IDE-Generated Build Mistakes

Sometimes the error text itself reveals a malformed dependency string. The title in this article is a good example: the displayed coordinate lost the normal separators in one place. That often happens because an IDE copied a human-readable string badly, or because the dependency was typed incorrectly in a UI form.

Always compare the actual pom.xml or build.gradle against the expected groupId, artifactId, and version format.

When Version 2.3.0.RELEASE Is the Wrong Choice

If you are starting a new project, using Spring Boot 2.3.0.RELEASE today is usually unnecessary technical debt. Older versions can still exist in repositories and still be resolvable, but they are not the right baseline for new work.

If the project is not locked to that version for compatibility reasons, upgrading the Boot version may be the better long-term fix.

Common Pitfalls

• Hardcoding a starter version instead of letting Spring Boot manage starter versions.
• Forgetting mavenCentral() or using a broken internal repository mirror.
• Refreshing caches before checking whether the dependency declaration itself is malformed.
• Mixing incompatible Spring Boot plugin, parent, and starter versions.
• Assuming the artifact is missing globally when the real issue is local repository configuration.

Summary

• The artifact is usually resolvable if the build is configured correctly.
• Prefer the Spring Boot parent or plugin-managed dependency setup.
• Use mavenCentral() unless your organization intentionally routes through a mirror.
• Clear local caches only after confirming the coordinates and repositories are correct.
• For new work, reconsider whether Spring Boot 2.3.0.RELEASE is the version you actually want.