Fix: Gradle Could Not Resolve Dependencies Error

The Error

You run a Gradle build and it fails with:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
   > Could not find org.springframework:spring-core:6.1.4.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/org/springframework/spring-core/6.1.4/spring-core-6.1.4.pom
     Required by:
         project :

Or one of these variations:

Could not resolve all files for configuration ':runtimeClasspath'.
> Could not resolve com.google.guava:guava:33.0.0-jre.
  Required by:
      project :app
   > No matching variant of com.google.guava:guava:33.0.0-jre was found.

Could not resolve all dependencies for configuration ':app:debugCompileClasspath'.
> Could not find com.example:internal-lib:1.0.0.

The build stops. None of your dependencies download. Nothing compiles.

Why This Happens

Gradle resolves dependencies by searching repositories you declared in your build.gradle or build.gradle.kts file. When it cannot find an artifact in any of those repositories, it throws a “Could not resolve dependencies” error.

The root causes fall into a few categories:

• Missing or misconfigured repositories. The dependency exists, but you have not told Gradle where to look for it.
• Offline mode is enabled. Gradle is not allowed to reach the network, so it can only use what is already cached locally.
• A proxy or firewall blocks the connection. Gradle tries to reach the repository but the network blocks it.
• Version conflicts. Two or more dependencies pull in incompatible versions of the same transitive dependency.
• Stale or corrupted local cache. Gradle cached a failed resolution and keeps reusing it instead of retrying.
• The artifact genuinely does not exist. The version you specified was never published, or the group/artifact ID is wrong.
• Multi-project build misconfiguration. A subproject dependency is not wired up correctly.

Each of these causes has a different fix. Work through the ones below in order.

Fix 1: Check and Add the Correct Repository

Gradle only searches repositories you explicitly declare. If you depend on a library hosted on Maven Central but your build.gradle only declares google(), Gradle will never find it.

Open your build.gradle (or build.gradle.kts) and check the repositories block:

// build.gradle
repositories {
    mavenCentral()
    google()
}

// build.gradle.kts
repositories {
    mavenCentral()
    google()
}

If the dependency comes from a private or third-party repository, add it explicitly:

repositories {
    mavenCentral()
    maven {
        url = uri("https://jitpack.io")
    }
    maven {
        url = uri("https://your-company.com/maven-repo")
        credentials {
            username = project.findProperty("repoUser") ?: ""
            password = project.findProperty("repoPassword") ?: ""
        }
    }
}

Store credentials in ~/.gradle/gradle.properties, not in build.gradle:

repoUser=your-username
repoPassword=your-token

Note: In multi-project builds, repositories declared in the root build.gradle do not automatically apply to subprojects. You may need a subprojects or allprojects block:

allprojects {
    repositories {
        mavenCentral()
        google()
    }
}

Or, in newer Gradle versions, use the dependencyResolutionManagement block in settings.gradle:

// settings.gradle
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenCentral()
        google()
    }
}

This centralizes repository declarations and prevents subprojects from adding their own, which reduces inconsistency.

Verify that the artifact actually exists in the repository. Open the repository URL in your browser and navigate to the group/artifact/version path. If it returns a 404, the artifact is not there and you need a different repository or version.

Fix 2: Disable Offline Mode

Gradle has an offline mode that prevents all network access. If it is enabled, Gradle can only resolve dependencies that are already in your local cache. Anything not cached will fail.

Check if you are passing the --offline flag:

# This forces offline mode
gradle build --offline

Remove the --offline flag and run the build again:

gradle build

Also check your gradle.properties for the offline flag:

# Remove or comment out this line
# org.gradle.offline=true

In IntelliJ IDEA, offline mode can be enabled through the Gradle settings. Go to Settings > Build, Execution, Deployment > Build Tools > Gradle and uncheck Offline work.

In Android Studio, check File > Settings > Build, Execution, Deployment > Gradle and make sure offline mode is disabled. Older versions of Android Studio had a dedicated toggle in the Gradle panel toolbar.

Fix 3: Configure Proxy and Firewall Settings

If you are behind a corporate proxy, Gradle cannot reach external repositories without proxy configuration. You will typically see connection timeouts or “unable to resolve” errors.

Add proxy settings to ~/.gradle/gradle.properties:

systemProp.http.proxyHost=proxy.example.com
systemProp.http.proxyPort=8080
systemProp.http.proxyUser=your-username
systemProp.http.proxyPassword=your-password
systemProp.http.nonProxyHosts=localhost|127.0.0.1|*.internal.example.com

systemProp.https.proxyHost=proxy.example.com
systemProp.https.proxyPort=8080
systemProp.https.proxyUser=your-username
systemProp.https.proxyPassword=your-password

Warning: You must configure both http and https proxy settings separately. Configuring only one will leave the other protocol unproxied.

If your company uses a custom SSL certificate for MITM inspection, you may also need to import the certificate into the Java truststore that Gradle uses:

keytool -importcert -alias company-proxy \
  -file /path/to/company-cert.crt \
  -keystore $JAVA_HOME/lib/security/cacerts \
  -storepass changeit

Test connectivity by running:

gradle build --info 2>&1 | grep -i "proxy\|connect\|timeout"

This shows detailed connection logs. Look for timeout errors or proxy negotiation failures. If you see java.net.ConnectException or javax.net.ssl.SSLHandshakeException, the proxy or SSL configuration is the problem.

If you use Maven for other projects, note that Gradle’s proxy configuration is different from Maven’s settings.xml. They do not share proxy settings. See how to fix Maven dependency resolution errors for Maven-specific proxy setup.

Fix 4: Resolve Version Conflicts

When two dependencies require different versions of the same transitive dependency, Gradle’s default strategy picks the highest version. But sometimes the highest version is binary-incompatible with one of the consumers, and the build breaks with a different error downstream — or Gradle itself fails to resolve the conflict.

First, inspect the dependency tree to find the conflict:

gradle dependencies --configuration compileClasspath

This prints a tree showing every dependency and its transitive pulls. Look for version mismatches — lines ending with -> X.Y.Z show where Gradle changed a version:

+--- com.squareup.okhttp3:okhttp:4.12.0
|    \--- com.squareup.okio:okio:3.7.0
\--- some.library:that-needs-old-okio:1.0.0
     \--- com.squareup.okio:okio:2.10.0 -> 3.7.0

Here, okio 2.10.0 was requested but Gradle upgraded it to 3.7.0 because okhttp pulled the newer version. If that-needs-old-okio is not compatible with okio 3.x, you have a problem.

Force a specific version using a resolution strategy:

configurations.all {
    resolutionStrategy {
        force 'com.squareup.okio:okio:3.7.0'
    }
}

Or in Kotlin DSL:

configurations.all {
    resolutionStrategy {
        force("com.squareup.okio:okio:3.7.0")
    }
}

For more granular control, use strictly in the dependency declaration:

implementation('com.squareup.okio:okio') {
    version {
        strictly '3.7.0'
    }
}

If the conflict causes a NoSuchMethodError at runtime instead of a build-time failure, the resolution happened but picked an incompatible version. See how to fix Java NoSuchMethodError for runtime classpath debugging.

Pro Tip: Run gradle dependencyInsight --dependency okio --configuration compileClasspath to see exactly why a specific dependency was resolved to a particular version. This is far more useful than scanning the full dependency tree when you already know which artifact is causing trouble.

Fix 5: Force Refresh Dependencies

Gradle caches dependency metadata and artifacts in ~/.gradle/caches/. If a download was interrupted or a repository returned a temporary error, Gradle may have cached a “not found” marker. Subsequent builds reuse this marker and keep failing even though the artifact is now available.

Force Gradle to re-download everything:

gradle build --refresh-dependencies

This flag tells Gradle to ignore cached metadata and re-check all repositories. It does not delete the cache — it just bypasses it for this build.

If --refresh-dependencies does not help, delete the cache manually:

# Delete the entire Gradle cache (all projects)
rm -rf ~/.gradle/caches/

# Delete only module metadata and artifacts
rm -rf ~/.gradle/caches/modules-2/

On Windows:

Remove-Item -Recurse -Force "$env:USERPROFILE\.gradle\caches\modules-2"

After deleting the cache, run the build again. Gradle will re-download everything from scratch.

Warning: Deleting ~/.gradle/caches/ removes caches for all Gradle projects on your machine, not just the current one. The next build for every project will be slower as it re-downloads everything. If you only want to clear a specific dependency, delete its folder under ~/.gradle/caches/modules-2/files-2.1/.

This is analogous to how Maven’s local repository can become corrupted. If you work with both build tools, see fixing Maven’s dependency resolution errors for the Maven equivalent.

Fix 6: Fix the Dependency Cache with Locking and Verification

Gradle supports dependency verification and locking to prevent silent changes or corrupted artifacts. If your project uses these features and they are misconfigured, builds will fail with resolution errors.

Dependency Verification

If your project has a gradle/verification-metadata.xml file, Gradle checks downloaded artifact checksums against expected values. A mismatch causes a resolution failure:

Dependency verification failed for configuration ':compileClasspath'

To regenerate the verification metadata after adding or updating dependencies:

gradle --write-verification-metadata sha256 build

This updates gradle/verification-metadata.xml with the correct checksums for all current dependencies.

Dependency Locking

If your project uses dynamic versions (like 2.+ or latest.release) with dependency locking, Gradle pins resolved versions in lock files. When a locked version is no longer available, resolution fails.

Update the lock files:

gradle dependencies --write-locks

Or for a specific configuration:

gradle dependencies --configuration compileClasspath --write-locks

If you do not use dependency locking intentionally, check for activateDependencyLocking() in your build scripts and remove it:

// Remove this if you don't want locking
dependencyLocking {
    lockAllConfigurations()
}

Fix 7: Use Dependency Exclusions and Substitutions

Sometimes you cannot fix a dependency conflict by forcing a version. The problematic transitive dependency needs to be excluded entirely, or replaced with a different module.

Exclude a Transitive Dependency

If a library pulls in a dependency that conflicts with another part of your project, exclude it:

implementation('com.example:some-library:1.0.0') {
    exclude group: 'org.slf4j', module: 'slf4j-log4j12'
}

This is common with logging frameworks. Many libraries bundle a specific SLF4J binding, but your project uses a different one. Excluding the unwanted binding prevents the conflict.

For a project-wide exclusion:

configurations.all {
    exclude group: 'org.slf4j', module: 'slf4j-log4j12'
}

Substitute a Module

Gradle lets you replace one dependency with another. This is useful when a library has been renamed or when you want to redirect all references to a single implementation:

configurations.all {
    resolutionStrategy {
        dependencySubstitution {
            substitute module('org.old:deprecated-lib') using module('org.new:replacement-lib:2.0.0')
        }
    }
}

A common real-world use case is Jakarta EE migration, where javax.* packages were renamed to jakarta.*:

configurations.all {
    resolutionStrategy {
        dependencySubstitution {
            substitute module('javax.servlet:javax.servlet-api') using module('jakarta.servlet:jakarta.servlet-api:6.0.0')
        }
    }
}

Common Mistake: Excluding a transitive dependency without providing a replacement can cause ClassNotFoundException or NoClassDefFoundError at runtime. Only exclude a dependency if you know another path already provides it, or if you are replacing it with a substitute. If you hit a ClassNotFoundException after exclusions, see how to fix Java ClassNotFoundException for debugging steps.

Use a Bill of Materials (BOM)

A BOM aligns versions across a set of related libraries. This eliminates most version conflicts within that set:

dependencies {
    implementation platform('org.springframework.boot:spring-boot-dependencies:3.2.4')
    implementation 'org.springframework:spring-core'
    implementation 'org.springframework:spring-web'
    // No version needed — the BOM controls it
}

Spring Boot, AWS SDK, and Google Cloud all publish BOMs. If you are pulling in multiple libraries from the same ecosystem, use the BOM to avoid manual version alignment.

Fix 8: Fix Multi-Project Build Configuration

In Gradle multi-project builds, dependency resolution errors often come from incorrect project references or missing configuration in subprojects.

Incorrect Project Dependencies

If a subproject depends on another subproject, use the project() syntax:

// In subproject-b/build.gradle
dependencies {
    implementation project(':subproject-a')
}

Make sure the referenced project is listed in settings.gradle:

// settings.gradle
rootProject.name = 'my-app'
include 'subproject-a', 'subproject-b'

If you see Could not find project :subproject-a, the project name in settings.gradle does not match. Check for typos, case sensitivity, and path separators.

Composite Builds

If you use includeBuild for composite builds, the included build must publish the artifacts that consumers expect:

// settings.gradle
includeBuild('../shared-library') {
    dependencySubstitution {
        substitute module('com.example:shared-library') using project(':')
    }
}

Without the dependencySubstitution block, Gradle will try to resolve com.example:shared-library from remote repositories instead of the local build.

Buildscript Dependencies

If the error mentions buildscript classpath resolution, the problem is in your build plugin dependencies, not your project dependencies. Check the buildscript block:

buildscript {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:8.3.0'
    }
}

The buildscript block has its own separate repositories section. Adding mavenCentral() to the project repositories block does not help plugin resolution. You need it in both places.

For the plugins DSL (preferred in modern Gradle), ensure settings.gradle has the plugin repositories configured:

// settings.gradle
pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
        google()
    }
}

If your build is failing with a Spring Bean creation error after fixing dependencies, the versions you resolved may be incompatible. Double-check that all Spring-related dependencies use the same major version.

Still Not Working?

If none of the fixes above solved the error, try these:

Upgrade Gradle itself. Older Gradle versions have known bugs in dependency resolution, especially with Gradle Module Metadata and variant-aware resolution. Check your current version:

gradle --version

Upgrade with the wrapper:

gradle wrapper --gradle-version 8.7

Then run the build with the wrapper:

./gradlew build

Check the Gradle wrapper version. If your project uses gradlew, the wrapper version in gradle/wrapper/gradle-wrapper.properties controls which Gradle version runs. Make sure it matches what your build scripts expect:

distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip

Run with debug output. The --info or --debug flags give detailed logs about which repositories Gradle checked, what HTTP responses it got, and why resolution failed:

./gradlew build --info

Search the output for the failing dependency name. You will see exactly which URLs Gradle tried and what response codes it got.

Check your Java version. Some dependencies require a minimum Java version. If you are running Java 8 but the dependency targets Java 17, Gradle may fail to resolve it because the metadata specifies a Java version constraint. Check your Java version with:

java -version

If you are using the wrong Java version, update JAVA_HOME or configure the toolchain in build.gradle:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

Look for typos in coordinates. A surprising number of resolution errors come from simple typos in the group ID, artifact ID, or version number. Double-check every character in the dependency declaration against the library’s official documentation or its page on Maven Central.

Check if the artifact was removed or relocated. Libraries sometimes change their Maven coordinates when they move to a new organization or undergo a major rewrite. Check the library’s GitHub repository or release notes for migration guides.