skip to content

How does BSP-based IDE sync differ from the legacy idea and eclipse Gradle plugins?

level: middleimportance: must knowfreq 35%

answer

  1. plugins generate files; BSP queries live
  2. .iml/.ipr vs .classpath/.project
  3. staleness + VCS noise
  4. IntelliJ uses Tooling API, not idea plugin
  5. didChange = incremental resync

basics

~20 s

The idea/eclipse plugins generate static metadata files (.iml/.ipr, .classpath/.project) on disk that an IDE reads. BSP is a live protocol where the IDE queries the build server on demand, with no generated files to drift out of date.

solid answer

~50 s

The **`idea`** and **`eclipse`** plugins implement **file generation**: running `./gradlew idea` or `./gradlew eclipse` produces IDE metadata on disk — `.ipr`/`.iml`/`.iws` for IntelliJ, `.project`/`.classpath`/`.settings` for Eclipse — which the editor then imports. These files are a **snapshot**: change a dependency and they go stale until regenerated, and they pollute version control. **BSP** is the opposite model: a **live, query-driven** protocol. The IDE connects to a build server and asks `workspace/buildTargets`, `buildTarget/sources`, etc. There are no generated files; the model is computed on demand and can be incrementally refreshed via `buildTarget/didChange`. Modern IDEs prefer dynamic integration — IntelliJ's native importer uses the Tooling API directly (not the `idea` plugin), and BSP is the standardized, multi-IDE version of that dynamic approach. The legacy plugins survive mainly for headless or unusual editors that still consume the static files; for everyday sync they are effectively deprecated in favor of dynamic integration.

code

kotlin · 14 lines
kotlin
// The legacy file-generation approach
plugins {
    idea
    eclipse
}
idea {
    module {
        isDownloadSources = true
        isDownloadJavadoc = true
    }
}
// ./gradlew idea    -> writes *.iml / *.ipr / *.iws
// ./gradlew eclipse -> writes .project / .classpath
// Modern IntelliJ/Buildship ignore these and import dynamically.

go deeper

for a junior

Know the plugins write files the IDE reads, whereas BSP asks the build tool live and nothing is generated.

for a middle

Contrast static generation vs live protocol, name the file types, and explain staleness/VCS drawbacks; know IntelliJ imports dynamically.

for a senior

Discuss when the legacy plugins still have a role, the beforeMerged/whenMerged hooks, and how dynamic integration maps to the Tooling API and BSP.

for a principal

Set org policy: prefer dynamic integration, gitignore generated IDE files, and standardize on a sync mechanism across editors to avoid drift.

## Two fundamentally different models ### Static file generation (idea / eclipse plugins) The `idea` and `eclipse` plugins are **declarative metadata generators**. You apply the plugin and run a generation task: - `gradle idea` -> `*.ipr` (project), `*.iml` (module), `*.iws` (workspace). - `gradle eclipse` -> `.project`, `.classpath`, `.settings/`. The IDE then opens those files. Both plugins expose DSL hooks (`idea { module { ... } }`, `eclipse { classpath { ... } }`) and lifecycle hooks (`beforeMerged`, `whenMerged`) to tweak the generated XML. Problems: - **Staleness** — a dependency or source-set change isn't reflected until you regenerate. - **VCS noise** — generated files are tempting to commit and cause churn/merge conflicts. - **Drift** — hand-edits in the IDE and regenerated output fight each other. ### Live protocol (BSP) / dynamic integration With BSP, nothing is written to disk as project metadata. The IDE holds a connection and **asks** the server for structure when it syncs, and the server can **push** `buildTarget/didChange` to trigger a scoped re-sync. The model always reflects the real, resolved build. This mirrors what IntelliJ already does natively via the **Tooling API** (`ProjectConnection`, custom model queries) — IntelliJ does **not** use the `idea` plugin to import. BSP standardizes this dynamic approach so any conforming editor gets it. ## Where each still fits - Use **dynamic integration (Tooling API / BSP)** for normal day-to-day development — it is the default and what IntelliJ/Buildship do. - Use the **`idea`/`eclipse` plugins** only for niche cases: tooling that genuinely needs the static files, or scripted/headless metadata generation. The Gradle docs themselves note these plugins are not needed for IDE import in modern IDEs. ## Quick comparison | Aspect | idea/eclipse plugins | BSP / dynamic | |---|---|---| | Mechanism | Generate static files | Live JSON-RPC queries | | Freshness | Stale until regenerated | Always current; didChange push | | VCS impact | Files tempt commits / conflicts | Nothing generated | | Granularity | Whole-project regen | Per-target incremental | | Modern IDE use | Rarely needed | Default path | ```kotlin // Legacy: still available, but not how IntelliJ imports plugins { idea } idea { module { isDownloadJavadoc = true } } // then: ./gradlew idea -> writes *.iml / *.ipr ```

  • Should you commit the generated .iml/.ipr or .classpath files?
    Generally no. They are derived, machine-specific, and prone to conflicts; modern IDEs reconstruct the model dynamically, so committing them adds churn with little benefit.
  • Does IntelliJ use the Gradle 'idea' plugin to import a project?
    No. IntelliJ's native Gradle importer uses the Tooling API to build a live model. The 'idea' plugin's file generation is a separate, mostly legacy mechanism.

The idea/eclipse plugins are like printing a paper map of the project; BSP is a live GPS that re-routes as the build changes.

saying these in an interview costs you the question

  • Saying you must run './gradlew idea' before opening a project in IntelliJ — the native importer doesn't need it.
  • Treating generated IDE files as the source of truth rather than the build script.

context

resolving links…