Fix Kotlin Gradle Dependency Resolution Errors for kotlin-stdlib-jre7

You will learn how Gradle resolves Kotlin dependencies, why a dependency can be “not found” even when its name is correct, and how repository declarations and compatible version choices fix the problem.

Gradle builds an application by downloading declared libraries—called dependencies—from one or more remote package repositories.

This dependency notation:

org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7

has three parts:

<group>:<artifact>:<version>

• Group: org.jetbrains.kotlin — the publisher or namespace.
• Artifact: kotlin-stdlib-jre7 — the library being requested.
• Version: 1.0.7 — the exact release.

The error does not necessarily mean Kotlin is installed incorrectly. It means Gradle searched the repositories configured for the project and did not find that exact artifact there.

For older Kotlin versions such as 1.0.7, the Kotlin runtime artifact was published to repositories such as Maven Central. A project must declare an appropriate repository before Gradle can download it.

This matters in real projects because every external library—Kotlin, AndroidX, Retrofit, test libraries, and plugins—must be available from a repository that Gradle is allowed to search.

Think of a Gradle dependency as a book request:

• The dependency coordinates are the book's author, title, and edition.
• A repository is a library branch Gradle is permitted to visit.
• Gradle checks each configured branch for that exact book.

If the book exists but no accessible branch carries it, Gradle reports that it could not find it. Adding the correct repository gives Gradle another place to look. Changing the version is like requesting an edition that the library actually stocks.

A traditional Android Gradle project commonly declares repositories in the top-level build.gradle file:

buildscript {
    repositories {
        google()
        mavenCentral()
    }

    dependencies {
        classpath "com.android.tools.build:gradle:2.2.3"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.0.7"
    }
}

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

The app module can then request the Kotlin standard library:

apply plugin: "kotlin-android"

android {
    compileSdkVersion 24
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7"
}

mavenCentral() is important here: it tells Gradle where to search for the Kotlin artifact.

In a modern Kotlin project, use a supported Kotlin version and the dependency notation generated by the current Kotlin tooling. Old Kotlin projects may use kotlin-stdlib-jre7; later Kotlin releases renamed JRE-targeted artifacts to kotlin-stdlib-jdk7. Do not change only the artifact name without also choosing a compatible Kotlin version.

Consider this simplified configuration:

allprojects {
    repositories {
        google()
    }
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7"
}

During the build, Gradle does the following:

1. It reads the dependency request for org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7.
2. It reads the configured repository list.
3. It searches google() for that exact group, artifact, and version.
4. If the artifact is not available from that repository, there are no other repositories to try.
5. Gradle stops dependency resolution and reports Could not find.

After adding Maven Central:

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

Gradle repeats the search, reaches Maven Central, downloads the artifact if it is available, stores it in the local Gradle cache, and continues the build.

Repository configuration is needed whenever a project obtains packages from outside its own source code.

• Android applications: Download Kotlin, AndroidX, Google, and third-party libraries.
• Backend services: Download web frameworks, database drivers, logging libraries, and testing tools.
• Company projects: Download internal packages from a private Maven repository.
• CI builds: Reproduce the same dependency download process on a clean build server.
• Legacy maintenance: Keep an old project building by ensuring repositories still host its pinned dependency versions.

For example, a company may use both Maven Central and an internal repository:

repositories {
    mavenCentral()
    maven {
        url = uri("https://packages.example.com/maven/releases")
    }
}

Gradle searches these repositories in the configured order.

In production codebases, developers usually centralize repository definitions rather than repeating them in every module.

Modern Gradle projects often define repositories in settings.gradle or settings.gradle.kts:

// settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

Teams also follow these practical patterns:

• Use supported versions: Upgrade old Kotlin, Gradle, and Android Gradle Plugin versions together according to their compatibility requirements.
• Keep versions consistent: The Kotlin Gradle plugin and Kotlin runtime should normally use compatible versions.
• Avoid dynamic versions: Prefer a fixed version such as 1.9.24 over 1.9.+ for reproducible builds.
• Centralize versions: Use a Gradle version catalog or shared build configuration to prevent modules from requesting conflicting versions.
• Inspect dependency graphs: Run a dependency report when transitive dependencies cause an unexpected version to be selected.

For example:

./gradlew :app:dependencies

This command helps show which libraries are requested and where version conflicts may exist.

Declaring the dependency but no repository

This fails when Gradle has nowhere appropriate to search:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7"
}

Add a repository in the build configuration that controls dependency resolution:

repositories {
    mavenCentral()
}

Adding a repository in the wrong place

In older Android Gradle layouts, adding a repository only inside buildscript.repositories may resolve build plugins but not app dependencies. App libraries are commonly resolved through allprojects.repositories.

buildscript {
    repositories {
        mavenCentral() // For buildscript dependencies
    }
}

allprojects {
    repositories {
        mavenCentral() // For application/module dependencies
    }
}

In newer builds, repository management may be located in settings.gradle instead.

Using an obsolete artifact name with a newer Kotlin version

kotlin-stdlib-jre7 belongs to older Kotlin-era naming. Later releases use kotlin-stdlib-jdk7. Follow the dependency declaration generated by the Kotlin version and Android tooling you are using.

Changing only one Kotlin version

Avoid upgrading the runtime while leaving a very old Kotlin Gradle plugin unchanged. Keep the Kotlin plugin and standard library compatible, preferably managed through one shared version.

Assuming cached dependencies prove a clean build will work

A local machine may have a library in Gradle's cache, while a CI server does not. Always declare the required repositories explicitly.

Adding deprecated repositories without a reason

Old tutorials may recommend repositories that are no longer maintained. Prefer google() and mavenCentral() for current Android projects, and add other repositories only when a required dependency documents them.

The artifact name is version-sensitive. Use the name expected by the Kotlin release you select rather than mixing naming conventions from different tutorials.

Dependency coordinate:
group:artifact:version

Example:
org.jetbrains.kotlin:kotlin-stdlib-jre7:1.0.7

// Older Gradle project layout
allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

// Modern settings.gradle.kts layout
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

• Could not find group:artifact:version usually means Gradle cannot locate that exact package in configured repositories.
• Check the artifact name, version, repository, network/proxy access, and private repository credentials.
• Use compatible Kotlin plugin and Kotlin runtime versions.
• kotlin-stdlib-jre7 is an older artifact name; newer Kotlin versions use kotlin-stdlib-jdk7 when that variant is needed.
• Prefer google() and mavenCentral() in current Android projects.

Why does Gradle say it cannot find a Kotlin dependency?

Gradle could not locate the exact group, artifact, and version in any configured repository. Add the repository that hosts it and verify the coordinates.

Is installing the Kotlin plugin in Android Studio enough?

No. The IDE plugin provides editor support, but Gradle still needs the Kotlin Gradle plugin, runtime dependency, and repository configuration to build the project.

Where should I add mavenCentral()?

In modern projects, add it to repository management in settings.gradle or settings.gradle.kts. In older projects, it is often declared in the root build file's allprojects { repositories { ... } } block.

What is the difference between kotlin-stdlib-jre7 and kotlin-stdlib-jdk7?

They are names used by different Kotlin release eras for Java 7-targeted standard-library variants. jre7 is the older naming; later versions use jdk7.

Should I keep using Kotlin 1.0.7?

Only if you are maintaining a historical project with strict compatibility constraints. For a new or actively maintained project, use a supported Kotlin version compatible with your Gradle and Android build tools.

Why does the build work on my machine but fail in CI?

Your machine may already have the artifact in its local Gradle cache. A clean CI environment must download it, so missing repositories, credentials, or network access become visible.

Can I fix this by using jcenter()?

Do not add repositories solely because an old tutorial suggests them. JCenter is deprecated; prefer Maven Central and Google repositories unless a dependency explicitly requires another source.

• Gradle dependency management — Declaring external libraries and controlling their versions.
• Maven repositories — The remote package sources Gradle searches.
• Gradle build plugins — Plugins that add build capabilities, including Kotlin compilation.
• Kotlin standard library — The runtime library that provides Kotlin's core APIs.
• Android Gradle Plugin — The Android-specific Gradle plugin that must be compatible with Gradle and Kotlin.
• Version catalogs — A modern way to centralize dependency coordinates and versions.
• Transitive dependencies — Libraries automatically requested by another library.
• Dependency caching — Gradle's local storage of downloaded artifacts, which can hide repository problems temporarily.