skip to content

The eclipse Plugin

4 roadmaps5 questions

The eclipse plugin's classpath, project, and WTP configuration and the descriptor files it writes. Asked alongside the idea plugin as the file-generation approach to IDE support.

on this pageshow

explore

questions

5

What does applying the 'eclipse' plugin to a Gradle build give you, and which files does it generate?

level: juniorimportance: must knowfreq 45%

answer

  1. generates .project / .classpath / .settings
  2. tasks: eclipseProject, eclipseClasspath, eclipseJdt
  3. eclipse + cleanEclipse lifecycle
  4. needs java plugin for source sets
  5. Buildship is the modern alternative

basics

~10 s

Applying eclipse adds tasks that generate Eclipse metadata files: .project and .classpath (and .settings). You run ./gradlew eclipse to create them and cleanEclipse to remove them.

solid answer

~30 s

The `eclipse` plugin generates the Eclipse IDE metadata so the project can be imported as a plain Eclipse Java project without Buildship. Applying it registers `eclipseProject` (writes `.project`), `eclipseClasspath` (writes `.classpath` from your dependency configurations and source sets), and a `.settings/org.eclipse.jdt.core.prefs` file for JDT compiler prefs. The aggregate `eclipse` task runs them all; `cleanEclipse` deletes them. It depends on the `java` (or `java-base`) plugin to know source sets and the runtime/compile classpaths. In modern workflows Buildship imports the build directly via the Tooling API instead, so this plugin is mostly for teams that want committed, static Eclipse files or non-Buildship setups.

code

kotlin · 7 lines
kotlin
plugins {
    java
    eclipse
}

// ./gradlew eclipse        -> writes .project, .classpath, .settings
// ./gradlew cleanEclipse   -> removes them

go deeper

for a junior

Know that eclipse/cleanEclipse generate and remove .project/.classpath, and that you run ./gradlew eclipse.

for a middle

Name the individual tasks (eclipseProject/eclipseClasspath/eclipseJdt) and where their data comes from (source sets + resolved configurations).

for a senior

Contrast committed static files vs. Buildship/Tooling-API sync and explain when each is appropriate.

for a principal

Set a team-wide policy on whether Eclipse metadata is committed, and how that interacts with reproducible imports across machines.

## What the `eclipse` plugin is The `eclipse` plugin is a Gradle core plugin that **generates Eclipse IDE metadata files** from your Gradle model. Eclipse traditionally describes a project with three artifacts: - `.project` — the project name, nature (e.g. Java nature), and builders. - `.classpath` — source folders, output folder, the JRE container, and library/dependency entries. - `.settings/org.eclipse.jdt.core.prefs` — JDT compiler settings (source/target compatibility). Applying the plugin gives you tasks that **write these files** so Eclipse can open the project as a regular (non-Gradle-aware) Java project. ## Apply it ```kotlin plugins { java eclipse } ``` ## Tasks it registers - `eclipseProject` → generates `.project`. - `eclipseClasspath` → generates `.classpath` (derives entries from `sourceSets` and the resolved `compileClasspath`/`runtimeClasspath`). - `eclipseJdt` → generates `.settings/org.eclipse.jdt.core.prefs`. - `eclipse` → lifecycle task that depends on all of the above. - `cleanEclipse` (and `cleanEclipseProject`, etc.) → deletes the generated files. ## Where the data comes from The plugin reads the `java` plugin's model: source sets become source-folder classpath entries, and the dependency configurations (compile/runtime classpath) become library entries pointing at the resolved jars in your Gradle cache. That is why the `eclipse` plugin implicitly needs the `java` (or `java-base`) plugin to do anything meaningful. ## Buildship vs. the eclipse plugin Modern Eclipse uses **Buildship**, which talks to Gradle over the **Tooling API** and synchronizes the classpath dynamically — you usually do NOT commit `.classpath`/`.project`. The `eclipse` plugin is for the older workflow of generating static, committed files, or for tooling that imports a vanilla Eclipse project. The two approaches can conflict, so pick one.

  • Which file does eclipseClasspath produce and what goes into it?
    `.classpath` — source-folder entries from your source sets, the JRE container, the output folder, and library entries derived from the resolved compile/runtime classpaths.
  • Why does the eclipse plugin need the java plugin?
    It reads source sets and the compile/runtime classpath configurations from the java model; without them there is nothing to write into `.classpath`.

saying these in an interview costs you the question

  • Saying the eclipse plugin replaces Buildship — it does the opposite, generating static files.
  • Claiming it works without the java plugin — it produces an essentially empty classpath.

context

resolving links…

open as a page

How do you customize the generated `.classpath` in Gradle — for example to mark a dependency as exported or tweak a classpath entry?

level: middleimportance: should knowfreq 35%

basics

~10 s

Use the eclipse.classpath block. Add extra containers, configure plusConfigurations/minusConfigurations, and use the file.whenMerged hook to mutate the in-memory classpath model (e.g. set entry.exported = true) before it is written.

open as a page

How do you customize the generated `.project` file — for example to add a project nature or build command?

level: middleimportance: should knowfreq 25%

basics

~10 s

Use eclipse.project { }. Set name, add natures("…") and buildCommand("…"), link folders with linkedResource, or use file.whenMerged/withXml to mutate the .project model before it's written.

open as a page

What is the `eclipse-wtp` plugin for, and how does it differ from the plain `eclipse` plugin?

level: seniorimportance: should knowfreq 20%

basics

~10 s

eclipse-wtp adds Web Tools Platform metadata for web/EE projects (WAR/EAR). It generates .settings/org.eclipse.wst.common.* files describing deployment assembly and facets, on top of the .project/.classpath the eclipse plugin produces.

open as a page

Should a team commit Gradle-generated Eclipse metadata files, or rely on Buildship? What are the trade-offs?

level: seniorimportance: nice to knowfreq 18%

basics

~20 s

Prefer Buildship, which syncs the classpath from Gradle via the Tooling API at import — don't commit .project/.classpath. The eclipse plugin's static files are for legacy or non-Buildship setups; if committed they drift and must be regenerated.

open as a page