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.

Diagnostic Timeline

Engineers under deadline pressure go straight to gradle build --refresh-dependencies and lose another twenty minutes when it doesn’t help. Here is the order an experienced JVM engineer actually works through this.

Minute 0 — Skip --refresh-dependencies. It only helps in one specific case: a cached negative result from a transient repository outage. If the artifact never existed at the URL Gradle searched, or if the network is broken at a lower layer, --refresh-dependencies just re-runs the same failing request. Do it after you have ruled out other causes, not before.

Minute 1 — Read the URL Gradle actually tried. The error message includes a line like Searched in the following locations: - https://repo.maven.apache.org/maven2/.... Open that URL in a browser. If it returns 404, the artifact does not exist at that coordinate — your group/artifact/version is wrong, or the artifact is in a different repository. If it returns 403, the repository requires authentication. If the browser hangs, your network cannot reach the repo at all (proxy, firewall, or DNS).

Minute 3 — Discriminate the four failure classes.

1. Coordinate wrong — typo, retracted version, or moved to new group ID (javax to jakarta, redis.clients to io.lettuce).
2. Repository missing — the artifact exists, but not in any repository you declared. JitPack, Spring Snapshots, and corporate Nexus instances are the usual missing entries.
3. Network broken — corporate proxy, MITM cert, or Maven Central rate limit (yes, this is real — 429 responses are increasingly common from CI runners on shared IPs).
4. Cache corruption — ~/.gradle/caches/modules-2/files-2.1/<group>/<artifact>/<version>/ contains a 0-byte .jar or a .pom that was truncated mid-download.

Minute 5 — The wrong path: deleting ~/.gradle/caches. Tempting, but it nukes every project’s cache and your next build downloads 600 MB. Surgically delete only the broken artifact: rm -rf ~/.gradle/caches/modules-2/files-2.1/<group>/<artifact>/<version>/. If you cannot identify the culprit, then --refresh-dependencies first.

Minute 7 — Check the proxy MITM cert. Corporate networks often inject a self-signed certificate. If Maven Central returns javax.net.ssl.SSLHandshakeException: PKIX path building failed, your JVM does not trust the corporate root CA. The fix is not disabling SSL verification (which some Stack Overflow answers shamefully recommend). Import the certificate into the JVM truststore (keytool -importcert ...) or configure Gradle to use a custom truststore via systemProp.javax.net.ssl.trustStore in gradle.properties.

Minute 9 — Check settings.gradle repository order. Modern Gradle’s dependencyResolutionManagement block in settings.gradle takes precedence over repositories { ... } in build.gradle. If settings.gradle declares RepositoriesMode.FAIL_ON_PROJECT_REPOS, any repository you added in build.gradle is silently ignored. Run gradle --info build and search for Repositories evaluated to see what Gradle actually used.

Minute 12 — Inspect mavenLocal carefully. mavenLocal() is convenient but treacherous: a truncated artifact in ~/.m2/repository poisons every subsequent resolution. If mavenLocal() is in your repository list and you have ever run a partial Maven build, suspect it first. Either remove mavenLocal() for CI builds or wipe ~/.m2/repository/<group>/<artifact>/ for the failing coordinate.

Real root-cause distribution: roughly 30% typo in coordinates or wrong version, 25% missing repository (especially for JitPack or in-house Nexus), 20% proxy/firewall/MITM cert, 15% cache corruption (the part --refresh-dependencies actually fixes), 10% Gradle Module Metadata variant mismatch with the wrong JVM target. Work the list in that 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 — a half-downloaded artifact in ~/.m2/repository produces the same kind of opaque resolution failure even though the file exists on disk.

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, or pin them with a Spring Boot BOM as shown in Fix 7.

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.

Look for Maven Central rate limiting on CI. Maven Central enforces rate limits on shared IPs. CI runners on GitHub Actions, GitLab SaaS, and CircleCI hit these limits regularly during peak hours. The symptom is intermittent Could not GET errors with HTTP 429 (sometimes masked as a generic timeout). Configure a mirror — Maven Central’s CDN mirror (https://repo1.maven.org/maven2/), Google’s Maven Central mirror, or your own Nexus/Artifactory — to avoid the shared rate bucket. Add it as the first repository in your resolution order so it is hit before mavenCentral().

Inspect Gradle Module Metadata variant rejection. Gradle 6+ uses Gradle Module Metadata (.module files) to expose multiple variants of an artifact (JVM, Android, native, JDK 8 vs JDK 17). The error No matching variant of com.example:lib:1.0 means the artifact exists but does not publish a variant compatible with your project’s attributes. Run gradle dependencyInsight --dependency com.example:lib --configuration runtimeClasspath and look for the “Variant selection failures” section — it lists which attributes did not match. Common cause: your project targets JDK 17 but the artifact only ships a JDK 21 variant.

Check the Gradle daemon for cached configuration. The Gradle daemon caches build script evaluation. If you edit build.gradle to add a repository but the daemon does not pick up the change, builds still fail with the old configuration. Force a daemon restart:

./gradlew --stop
./gradlew build

This is faster than restarting your machine and is the right first move whenever Gradle’s behavior seems inconsistent with what is in the build files.

Look for settings.gradle RepositoriesMode.FAIL_ON_PROJECT_REPOS. This mode rejects any repositories { ... } block in subproject build.gradle files. If you migrated from per-project repositories to centralized ones, leftover declarations in subprojects either fail loudly (good) or are silently ignored (bad, depending on Gradle version). Centralize all repositories in settings.gradle’s dependencyResolutionManagement block to avoid the ambiguity.

Confirm gradle.properties is being loaded. Settings in ~/.gradle/gradle.properties apply globally, settings in <project>/gradle.properties apply per project. The project file wins. If you set proxy settings globally but a project’s local gradle.properties lacks them, that project cannot reach external repositories. Print the effective properties with gradle properties | grep -i proxy to verify.