/개발/Gradle "Could not resolve dependencies" Error: 6 Cause-by-Cause Fixes
DevelopmentGradle의존성에러

Gradle "Could not resolve dependencies" Error: 6 Cause-by-Cause Fixes

Fix Gradle "Could not resolve dependencies" and "Could not find artifact" errors in 5 minutes with diagnostic commands and copy-paste snippets for six causes: repositories, authentication, proxy, SSL, cache, and multi-module.

Gradle "Could not resolve dependencies" Error: 6 Cause-by-Cause Fixes

Gradle "Could not resolve dependencies" Error: 6 Causes, 5-Minute Fixes

When this shows up in red in your build log, your heart sinks.

CODE
* What went wrong:
Could not resolve all files for configuration ':app:runtimeClasspath'.
> Could not find com.example:some-lib:1.2.3.
> Could not resolve com.squareup.okhttp3:okhttp:4.12.0.

Bottom line: these three error messages are essentially the same thing. Gradle is just describing the same event—"I couldn't fetch the JAR at the coordinates you asked for from anywhere"—at different stages. We'll skip the theory and go straight to error → diagnostic command → copy-paste fix.

30-Second Diagnostic Flowchart and Universal First Commands

No matter what you suspect, run these two commands first.

Bash
# 1) 의존성 트리와 어떤 저장소를 뒤졌는지 상세 로그로 확인
./gradlew dependencies --info

# 2) 캐시 무시하고 강제로 다시 받아오기 (캐시 손상이면 이걸로 끝남)
./gradlew build --refresh-dependencies

Read the logs and branch from there.

Clue in the error messageLikely causeJump to
Could not find artifact / coordinates (group:name:version)Repository or coordinatesCauses 1·2·3
unable to find valid certification pathSSL certificateCause 4
Connection timed out / internal URLProxy or firewallCause 4
Module path like :moduleA:Multi-module repository splitCause 6
Worked yesterday, broke todayCorrupted cacheCause 5

Cause 1 — Missing repositories block / jcenter() shutdown

This is the most common one. JCenter has been shut down since 2021 and no longer responds. If a legacy build still has jcenter(), it will fail as-is.

Diagnose:

Bash
./gradlew dependencies --info | grep -i "repositor\|jcenter"

Fix (Groovy DSL):

GROOVY
// build.gradle - 수정 전
repositories {
    jcenter()   // ❌ 종료됨
}

// 수정 후
repositories {
    mavenCentral()
    google()    // Android 의존성(androidx 등)이라면 필수
}

Kotlin DSL:

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

If the repositories block is missing entirely, Gradle has nowhere to look. If you can't resolve androidx after an AGP upgrade, it's almost certainly a missing google().

Cause 2 — Internal Nexus / Artifactory auth and proxy

Internal repositories often return 401/403 when auth is blocked, which Gradle disguises as "Could not find". Don't hardcode credentials—put them in gradle.properties.

PROPERTIES
# ~/.gradle/gradle.properties (개인 홈, 커밋 금지)
nexusUser=your-id
nexusPassword=your-token
KOTLIN
// build.gradle.kts
repositories {
    maven {
        url = uri("https://nexus.mycorp.com/repository/maven-public/")
        credentials {
            username = providers.gradleProperty("nexusUser").get()
            password = providers.gradleProperty("nexusPassword").get()
        }
    }
    mavenCentral()
}

Practical tip: Whenever this breaks on the corporate network, I try fetching the JAR directly with curl -u id:token https://nexus.../path/to.jar. If curl succeeds, it's a Gradle config issue; if curl also gets 401, it's a permissions/token problem—you can split the cases in 5 seconds.

Cause 3 — Version/coordinate typos / missing BOM

A single typo in the group or version of com.example:lib:1.2.3 produces "Could not find artifact". Versions scattered across modules also drift out of sync; aligning them with a BOM (platform()) keeps things clean.

KOTLIN
dependencies {
    // BOM으로 버전 일괄 고정 → 개별 버전 생략 가능
    implementation(platform("com.fasterxml.jackson:jackson-bom:2.17.1"))
    implementation("com.fasterxml.jackson.core:jackson-databind") // 버전 X

    // 강제 정렬이 필요하면 enforcedPlatform
    implementation(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:3.3.0"))
}

Diagnose by targeting a specific module and configuration:

Bash
./gradlew :app:dependencies --configuration runtimeClasspath

Cause 4 — Firewall, proxy, and SSL certificates

If you see unable to find valid certification path to requested target, the corporate CA isn't in the JDK trust store. Start with proxy settings:

PROPERTIES
# gradle.properties
systemProp.https.proxyHost=proxy.mycorp.com
systemProp.https.proxyPort=8080
systemProp.https.nonProxyHosts=*.mycorp.com|localhost
systemProp.http.proxyHost=proxy.mycorp.com
systemProp.http.proxyPort=8080

Import the corporate CA into the JDK cacerts:

Bash
keytool -importcert -alias mycorp-ca \
  -file mycorp-ca.crt \
  -keystore "$JAVA_HOME/lib/security/cacerts" \
  -storepass changeit

If you've hit the same SSL symptom in another tool (e.g. "unable to get local issuer certificate"), see the dedicated post for that. Here we only cover the Gradle/JDK trust store.

Cause 5 — Corrupted Gradle cache

The usual culprit behind "it worked yesterday". Stop the daemon first, then delete only the module cache—that's the safe approach.

Bash
# 1) 데몬 정지 (파일 잠금 해제)
./gradlew --stop

# 2) 모듈 캐시만 삭제 (전체 ~/.gradle 통째로 지우지 말 것)
rm -rf ~/.gradle/caches/modules-2

# 3) 강제 재다운로드
./gradlew build --refresh-dependencies

In IntelliJ/Android Studio, also run File → Invalidate Caches / Restart. IDE cache and Gradle cache are separate; clearing only one often leaves the other broken.

Cause 6 — Multi-module / plugin repository split

Gradle 8.x defaults to FAIL_ON_PROJECT_REPOS, so per-module repositories blocks are rejected. Centralize repositories in settings.gradle(.kts). Plugin repositories and dependency repositories are different blocks.

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

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

If the error message shows a module path like :moduleA:, suspect this first.

Wrap-up: Symptom → Command → One-line Fix Checklist

SymptomDiagnostic commandOne-line fix
Using jcenterdependencies --infojcenter()mavenCentral(), google()
Internal lib 401Test directly with curl -ucredentials { } + gradle.properties
Coordinate typo:app:dependenciesApply BOM platform()
SSL errorcert path in the logkeytool -importcert
Suddenly broken--refresh-dependencies--stop then delete modules-2
Module path shown:module:dependenciesdependencyResolutionManagement in settings

Quick routing: If you see artifact, start with causes 1 and 3; if you see a module path (:module:), start with 6.

Note: Similar dependency errors in other ecosystems—npm ERESOLVE, pip ResolutionImpossible, Python ModuleNotFoundError—have completely different stacks and fix angles, so they're covered in dedicated posts.

FAQ

Q. I still get "Could not find" even with --refresh-dependencies. A. It's probably a repository or coordinates problem, not the cache. Check which URLs Gradle actually tried with ./gradlew dependencies --info, then verify the JAR exists in that repository with a browser or curl.

Q. Can I just delete the entire ~/.gradle folder? A. Not recommended. You'll wipe wrapper distributions and global settings too. Stop the daemon with ./gradlew --stop, then delete only ~/.gradle/caches/modules-2.

Q. Gradle 8 rejects the build when I put repositories in build.gradle. A. That's the FAIL_ON_PROJECT_REPOS default. Move repositories into the dependencyResolutionManagement block in settings.gradle(.kts).

확인 정보
✦ ✦ ✦
편집 검토 · Editorial Review

Nodelog는 모든 콘텐츠의 내용과 출처를 공개 전에 검토합니다. 환경(OS·버전)에 따라 결과가 달라질 수 있는 기술 정보는 공식 문서와 함께 확인하며, 검토 기준과 정정 원칙은 편집 정책에서 안내합니다. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.

편집 책임 · Nodelog 기술 편집팀·발행 · ·업데이트 ·

Comments

Be the first to comment.