Unexplainable "dependency cannot be resolved"

Totally stumped. I have the world’s simplest build.gradle with a single dependency. Yet I continue to get dependency cannot be resolved errors
build.gradle.kts

plugins {
    id("java")
}
group = "org.example"
repositories {
    mavenCentral()
}
dependencies {
    implementation("org.apache.commons:commons-math3:3.6.1")
}

command:

.\gradlew -q dependencies --configuration implementation
------------------------------------------------------------
Root project 'LearnJava'
------------------------------------------------------------
implementation - Implementation dependencies for the 'main' feature. (n)
\--- org.apache.commons:commons-math3:3.6.1 (n)
(n) - A dependency or dependency configuration that cannot be resolved.

Tried everything. e.g. confirming the artefact exists on MavenCentral(), removing .gradle/.cashes etc. Can you help?

You misinterpret the output a bit. :slight_smile:
The dependency is marked as “cannot be resolved” because it is in a configuration that cannot be resolved.
And implementation cannot be resolved as it is a “dependency scope” configuration where you declare dependencies, not a “resolvable” configuration that is used to resolve dependencies.
If you leave out the --configuration implementation or switch it for example to --configuration runtimeClasspath it should resolve fine.

Thanks for the reply. As you can tell I am still in the baby steps phase learning gradle. so still confused:

  • I have gradle 8.8.0 installed. The project is java / android studio.
  • I need to add a dependency on apache.commons.
  • My project has 3 subprojects. It has a build.gradle file at the top level and 3 build.gradle files under each of the subprojects.
  • adding dependencies {implementation “org.apache.commons:commons-math3:3.6.1” } to top level build.gradle seems to cause the download of the jars to ~/.gradle but the project fails to build (it can’t find the necessary commons classes).
  • replacing that with runtimeClasspath “org.apache.commons:commons-math3:3.6.1” per your suggestion I get a build failure with the error: Caused by: org.gradle.api.GradleException: Dependencies can not be declared against the runtimeClasspath configuration.
  • However, putting the [implementation “org.apache.commons:commons-math3:3.6.1”] in the build.gradle belonging to the subproject that needs the dependency seems to make things work. the commons classes are found etc.
    How should I try to reconcile these observations with your comments?
    Thanks!

I have gradle 8.8.0 installed. The project is java / android studio.

Actually, imho you should not have any Gradle version installed ever.
Each and every project should contain the 4 Gradle wrapper files and the Gradle wrapper should always be used to run a build, as it defines and manages the exact Gradle version that is used to run a build, so that it runs with the exact version it is designed for and known working with.

adding dependencies {implementation “org.apache.commons:commons-math3:3.6.1” } to top level build.gradle seems to cause the download of the jars to ~/.gradle but the project fails to build (it can’t find the necessary commons classes).

If you add the dependencies to the root project, but want to use it in the subproject, it of course fails, as you did not add it to the subproject. You need to declare a dependency where you need it, not at a random different place. :slight_smile:

replacing that with runtimeClasspath “org.apache.commons:commons-math3:3.6.1” per your suggestion

No, that was not my suggestion.
I said in your Gradle command where you list the dependencies, not when declaring the dependency.
There are three kinds of configurations, configurations you declare your dependencies on (like implementation, compileOnly, or runtimeOnly), configurations that are used to resolve dependencies (like runtimeClasspath, or compileClasspath), and configurations that are used to provide results to other projects or builds (like runtimeElements).
Configurations can extend each other, for example runtimeClasspath extends implementation and runtimeOnly. On the latter two you declare dependencies according to the needs, with the former all dependencies that are needed at runtime are resolved.


Btw. I strongly recommend to switch to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpful error messages if you mess up the syntax, and an amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio.

Thanks. really helpful. hard to find conclusive information about gradle on-line. I actually also feel the on-line documentation is just incomplete. btw, I am aware of gradlew. i just misspoke, I meant to say gradle 8.8 is configured for my project.

  • what would be really helpful is a document, or a gradle command that lists the hierarchy of configurations, the attributes for each (resolvable etc.) and which ones are used in different gradle commands. for example, what configuration does the ‘gradlew build’ command use? does such a document exist in one place?
  • Also would have been very helpful is to have some sort of overall design document. a flow chart of how gradle works perhaps. the online documentations are more like a ‘parts list’ rather than a coherent introduction to the system. Any source you can point me to?
  • Is there a path to migrating a project from groovy to kotlin? is it just a matter of renaming the build.gradle files and changing the code within to be compatible with kotlin? What if you miss some files, would it be a problem to have a mixture of build.gradle build.gradle.kts files?

hard to find conclusive information about gradle on-line

I don’t really agree. :slight_smile:
I find the user manual quite good for a software tool documentation. :smiley:
Blogs, SO answers, and so on are often a bit outdated or bad practice though, yes.

I actually also feel the on-line documentation is just incomplete.

In what regard?
The one-page version misses some parts due to reasons :frowning:
If you miss other information, it might be worth opening an improvement ticket.

I am aware of gradlew. i just misspoke, I meant to say gradle 8.8 is configured for my project.

:ok_hand:

what would be really helpful is a document,

That is hard to document, as it depends on what plugins you apply.
Each plugin you apply can add further configurations or link configurations together or also your build scripts can do that.
And some also are more an implementation detail.
So it would usually be up to the plugins you use to document which configurations they add, how they relate, and what to use.
There is for example The Java Plugin Figures 2 and 3 which show it for the java plugin.
Or The Java Library Plugin for the java-library plugin.

or a gradle command that lists the hierarchy of configurations

I’m not aware of one listing the hierarchy.
There is the task resolvableConfigurations that at least shows the resolvable configurations and from which they extend from.

which ones are used in different gradle commands. for example, what configuration does the ‘gradlew build’ command use?

That is not really possible technically I think.
Especially the build task does not use anything, it is a lifecycle task that just depends on other tasks.
Which tasks it depend on depends on the plugins you apply and what you configure in your build script.
But telling which task uses what configuration I don’t think is easily listable as things can for example also be mapped / transformed / etc., or depended on transitively.

Any source you can point me to?

You mean like this: Getting Started ?
If not, you probably need to ask more concrete about what you are interested in.

Is there a path to migrating a project from groovy to kotlin?

https://docs.gradle.org/current/userguide/migrating_from_groovy_to_kotlin_dsl.html

is it just a matter of renaming the build.gradle files and changing the code within to be compatible with kotlin?

Basically, yes.

What if you miss some files, would it be a problem to have a mixture of build.gradle build.gradle.kts files?

No, both can coexist without a problem.