Best Practice: Optimizing Scans for Large Java/Kotlin Gradle Projects

Last updated: March 6, 2026

Context

Large Gradle repositories can experience long scan times due to dependency resolution cost, Gradle startup/configuration overhead across many subprojects, and remote metadata lookups. This is especially visible in monorepos, repos with many package versions, and CI environments with cold caches.

This article describes the recommended approach to improve scan performance while preserving scan reliability and predictable runtime.

Guidance

1. Reduce redundant Gradle operations across large monorepos

  • Prerequisite: gradlew must be available in the scan environment.

  • What: Set the environment variable ENDOR_SCAN_GRADLE_MONOREPO_MODE=true in the scan environment.

  • Why: This changes scan execution shape to avoid many repeated unresolved/resolved task calls per project.

Benchmarked Gradle projects had a scan drop from 4 hours ➡ 12 minutes with ENDOR_SCAN_GRADLE_MONOREPO_MODE=true

2. Force-Cache the build artifacts across all packages

  • Prerequisites:

    • For Maven, make sure that mvn install -U is successful and include mvn dependency and mvn help plugins in the local m2 cache.

    • For Gradle complete gradle assemble --refresh-dependencies.

  • What:

    Use the --use-local-repo-cache parameter as an input to endorctl scan parameters to se the local cache for dependency resolution. 

  • Why: Avoid the network overhead of re-resolving the dependencies into the pipeline.

3. Scope the scans by packages and languages.