skip to content

Project and File Dependencies

6 roadmaps5 questions

Depending on another project with project(':lib'), on loose files with files() and fileTree(), and on Gradle's own API. Interviewers ask because file dependencies carry no metadata and silently opt out of variant-aware resolution.

on this pageshow

explore

questions

5

How do you declare a dependency on another module within the same Gradle multi-project build, and how does it differ from depending on an external library?

level: juniorimportance: must knowfreq 70%

answer

  1. project(':lib') not a coordinate
  2. logical path from settings, not filesystem
  3. implicit task dependency — builds first
  4. consumes apiElements/runtimeElements
  5. no publish, incremental

basics

~10 s

Use project(':lib') instead of a coordinate string, e.g. implementation(project(':lib')). Gradle wires the local subproject directly rather than resolving it from a remote repository.

solid answer

~30 s

Within a multi-project build you declare a **project dependency** with the `project(':path')` notation: `implementation(project(':lib'))`. The colon-separated path is the logical project path (from `settings.gradle(.kts)`), not a filesystem path. Unlike an external dependency — declared as a `group:name:version` coordinate that Gradle resolves from a repository — a project dependency points at a sibling subproject in the same build. Gradle builds that subproject first (it becomes a task dependency), then consumes its produced artifact and its transitive dependencies through the producer's `apiElements`/`runtimeElements` outgoing configurations. This gives you incremental, source-aware builds: changing `:lib` rebuilds and re-tests dependents without publishing anything.

code

kotlin · 8 lines
kotlin
// settings.gradle.kts
include(":app", ":lib")

// app/build.gradle.kts
dependencies {
    implementation(project(":lib"))                 // local subproject
    implementation("com.google.guava:guava:33.0.0-jre") // external module
}

go deeper

for a junior

Know the project(':lib') notation and that it points at a sibling module, not a downloaded artifact.

for a middle

Explain the implicit task dependency, transitive api propagation, and the path-is-logical-not-filesystem distinction.

for a senior

Discuss variant-aware wiring via apiElements/runtimeElements and how conflicts resolve in one graph.

for a principal

Frame when to keep code in-build as project deps vs. extracting to published libraries / composite builds for org-scale modularization.

## What a project dependency is A Gradle build can contain many **subprojects** (also called modules or projects), each declared in `settings.gradle(.kts)` via `include(":app", ":lib")`. The leading colon and colons separating segments form a **logical project path** (`:lib`, `:libs:core`), independent of where the directory actually lives on disk. When one subproject needs another, you declare a **project dependency**: ```kotlin dependencies { implementation(project(":lib")) } ``` ## How it differs from an external dependency - **External / module dependency**: `implementation("com.google.guava:guava:33.0.0-jre")` — a `group:name:version` coordinate that Gradle **resolves** from a declared repository (Maven Central, etc.), downloading a published artifact and its POM/module metadata. - **Project dependency**: `project(":lib")` — points at a subproject in the *same build*. Nothing is downloaded; Gradle adds an implicit **task dependency** so `:lib` is assembled before its consumer, then wires the consumer's classpath to `:lib`'s outgoing artifacts. ## What gets wired under the hood Gradle uses **variant-aware** resolution. The producer (`:lib`) exposes *consumable* configurations such as `apiElements` (compile classpath) and `runtimeElements` (runtime classpath). The consumer's *resolvable* configurations (`compileClasspath`, `runtimeClasspath`) select the matching variant by attributes (e.g. `Usage`, `LibraryElements`). So `implementation(project(":lib"))` transitively brings in whatever `:lib` declared as `api` dependencies and the appropriate classes/jar. ## Practical consequences - **Incremental builds**: editing `:lib` triggers recompilation of dependents — no publish step. - **Up-to-date checks & build cache** work across the boundary. - The dependency participates in the same **dependency graph**, so version conflicts between `:lib`'s transitive deps and yours are resolved together. Use project dependencies for code you control inside the build; use coordinates for third-party or already-published artifacts.

  • Is `:lib` a filesystem path?
    No — it's a logical project path derived from `settings.gradle(.kts)`. The directory can be remapped with `project(":lib").projectDir = file("...")`.
  • Does Gradle publish `:lib` to a repository to make this work?
    No. It wires the consumer directly to the producer's outgoing artifacts in-build and adds a task dependency so `:lib` is built first.

An external dependency is ordering a part from a catalog; a project dependency is grabbing a part your own factory builds on the next bench — no shipping, and if you change the blueprint it's remade on the spot.

saying these in an interview costs you the question

  • Claiming `project(':lib')` is a path on disk.
  • Saying it requires publishing to mavenLocal first.
  • Confusing it with `includeBuild` (that's composite builds across separate builds).

context

resolving links…

open as a page

When and how would you declare a dependency on local JARs using `files()` and `fileTree()`, and what are the trade-offs versus repository-resolved dependencies?

level: middleimportance: should knowfreq 55%

basics

~10 s

Use implementation(files("libs/foo.jar")) for a specific JAR, or implementation(fileTree("libs") { include("*.jar") }) for a folder of JARs. They reference local files directly with no version metadata or transitive resolution.

open as a page

A teammate wired a project dependency `project(':lib')` but the other module lives in a separate Gradle build. Why does this fail, and what's the correct mechanism?

level: seniorimportance: should knowfreq 35%

basics

~10 s

project(':lib') only resolves subprojects included in the same build's settings.gradle(.kts). A module in a separate build isn't a subproject, so the path is unknown. Use includeBuild (a composite build) to substitute it.

open as a page

How do you depend on a specific producer configuration of another subproject, e.g. `project(path: ':lib', configuration: 'myConfig')`, and when is that useful?

level: seniorimportance: should knowfreq 30%

basics

~10 s

Use the map notation project(path: ':lib', configuration: 'instrumented') (Groovy) or project(":lib", configuration = "instrumented") (Kotlin) to consume a named outgoing configuration of the producer instead of its default variant.

open as a page

What are `gradleApi()` and `localGroovy()`, and where would you declare them?

level: middleimportance: nice to knowfreq 25%

basics

~10 s

They're dependency notations for building Gradle plugins. gradleApi() puts the Gradle API on the compile classpath; localGroovy() adds the Groovy version bundled with the running Gradle. You declare them in a plugin/buildSrc project's dependencies.

open as a page