How to add a dependency to another project using gradle (and eclipse)?

by

Summary

A developer encountered issues configuring project dependencies in a Gradle multi-project build when attempting to reference the Base module from other subprojects (App, Import). The root cause was misconfiguration in dependency declarations and Gradle-Eclipse integration, resulting in unresolved references despite correct project inclusion.

Root Cause

The problem stemmed from incorrect methods to declare project dependencies and IDE synchronization:

  • Using eclipse.project { referencedProjects("Base") } incorrectly handled build-time dependencies (only updates Eclipse IDE settings).
  • Using compile(project(":Base")) employed outdated Kotlin DSL syntax.
  • Missing dependency declarations in the dependencies block of subprojects (App, Import).

Why This Happens in Real Systems

Complex multi-project builds often face this due to:

  • Confusion between dependency scopes: Mixing IDE metadata (Eclipse configuration) with Gradle’s dependency management.
  • Legacy syntax carryover: Juniors copy outdated Groovy/Java examples to Kotlin DSL.
  • Implicit assumptions: Believing include(...) alone enables source-level dependencies.

Real-World Impact

Incorrect configuration causes:

  • Build failures during compilation due to unresolved symbols from Base.
  • IDE errors like red squiggles in Eclipse, misleading developers.
  • Project paralysis: Dependent modules (App, Import) cannot progress.

Example or Code

Implementation for App/build.gradle.kts (correct Kotlin DSL): 

dependencies {  
    implementation(project(":Base"))  
}

Required for Eclipse integration (settings.gradle.kts): 

rootProject.name = "Wrapper"  
include("Import", "Base", "App")

How Senior Engineers Fix It

Validate dependency scopes and syntax:

  1. Declare dependencies explicitly using implementation(project(":Base")) in dependencies blocks of consumer modules.
  2. Synchronize IDE projects using ./gradlew eclipse or Eclipse’s Gradle plugin (re-generates .project/.classpath).
  3. Prefer Gradle-native mechanisms (project dependencies) over Eclipse-specific hooks like eclipse.project.
  4. Verify transitive dependencies with ./gradlew :App:dependencies.

Why Juniors Miss It

Juniors often overlook:

  • Syntax nuances: Kotlin DSL’s parentheses are mandatory (project(":Base")) vs. Groovy’s project(":Base").
  • Dependency granularity: Assuming include(...) automatically configures source dependencies.
  • Tooling gaps: Not realizing IDE plugins (e.g., Buildship) require explicit Gradle tasks to update metadata.
  • Documentation traps: Reusing deprecated patterns (compile instead of implementation).