skip to content

When would you query EclipseProject vs IdeaProject vs GradleProject, and what does each expose?

level: middleimportance: should knowfreq 32%

answer

  1. GradleProject = tasks + project tree, no classpath
  2. EclipseProject = classpath/source dirs/natures (Buildship)
  3. IdeaProject/IdeaModule = JDK, language level, modules (IntelliJ)
  4. choose by needed data
  5. all read-only snapshots

basics

~10 s

GradleProject is the generic, tool-agnostic view (project tree, tasks). EclipseProject and IdeaProject are IDE-shaped views adding classpath, source dirs, dependencies, and (for IDEA) JDK/language level — used by Buildship and IntelliJ respectively.

solid answer

~40 s

Pick the model by what you need. **`GradleProject`** is generic: project name/path, build script, the task hierarchy, parent/children — use it for tooling that just needs the build's shape and tasks. **`EclipseProject`** is the Eclipse/Buildship view: classpath entries (project and external dependencies), source directories, output location, linked resources, natures/build commands — use it to drive an Eclipse import. **`IdeaProject`** (with `IdeaModule`) is the IntelliJ view: JDK name, language level, modules, content roots, and per-module dependencies — use it for IntelliJ-style import. EclipseProject and IdeaProject carry resolved dependency/classpath data that GradleProject deliberately omits. They're all read-only snapshots fetched with `getModel(...)`; choose the one whose getters match your tool's data needs rather than re-deriving it.

code

java · 5 lines
java
EclipseProject ep = connection.getModel(EclipseProject.class);
ep.getProjectDependencies().forEach(d ->
    System.out.println("project dep: " + d.getPath()));
ep.getClasspath().forEach(d ->
    System.out.println("jar: " + d.getFile()));

go deeper

for a junior

Know GradleProject = tasks/tree; the other two are IDE-specific.

for a middle

Contrast the data each exposes and pick by what the tool needs.

for a senior

Note that modern IDEs layer custom models on top, but built-ins remain the documented contract.

for a principal

Discuss model selection as part of an import architecture and the cost/coverage trade-off across Gradle versions.

## Three models, three audiences All three are read-only TAPI models, but they expose different slices: ### GradleProject (tool-agnostic) - `getName()`, `getPath()`, `getDescription()` - `getBuildScript()` (the build file) - `getTasks()` — the task tree (`GradleTask` with name, path, description, group) - `getParent()` / `getChildren()` — project hierarchy - `getBuildDirectory()`, `getProjectDirectory()` Use it when you only care about *what tasks exist* and *the project structure* — e.g. a generic task runner or a build-graph visualizer. It does **not** give you resolved dependencies or a classpath. ### EclipseProject (Eclipse / Buildship) - `getClasspath()` — external dependency entries (`EclipseExternalDependency`) - `getProjectDependencies()` — inter-project deps - `getSourceDirectories()`, `getLinkedResources()` - `getProjectNatures()`, `getBuildCommands()`, `getJavaSourceSettings()` This is the shape Eclipse/Buildship needs to create `.classpath`/`.project` data. ### IdeaProject + IdeaModule (IntelliJ) - `IdeaProject`: `getJdkName()`, `getLanguageLevel()`, `getModules()` - `IdeaModule`: `getContentRoots()`, `getDependencies()` (module + library), `getJavaLanguageSettings()` This is the IntelliJ import shape. (Modern IntelliJ also uses custom models, but the built-in IdeaProject remains the documented example.) ## How to choose Ask: *does my tool need resolved classpath/dependency info?* If yes, use the IDE model matching your target (Eclipse vs IDEA). If you only need the task/project tree, `GradleProject` is lighter and tool-neutral. Never re-derive classpath data by hand when the IDE model already computed it. ## Fetching ```java EclipseProject ep = connection.getModel(EclipseProject.class); for (EclipseExternalDependency d : ep.getClasspath()) { System.out.println(d.getFile()); } ``` All three honor the same `getModel` / `model(type)` mechanics and are serialized snapshots.

  • Why might GradleProject be insufficient for an IDE import?
    It exposes the project/task tree but not resolved dependencies, classpath entries, source directories, or JDK/language settings the IDE needs.
  • Which model gives you JDK name and language level?
    IdeaProject (with IdeaModule); GradleProject and EclipseProject don't expose IntelliJ-style JDK/language-level info in that form.

saying these in an interview costs you the question

  • Claiming GradleProject exposes resolved dependencies/classpath
  • Using EclipseProject to drive an IntelliJ import (wrong shape)
  • Manually re-resolving classpath instead of reading the IDE model

context

resolving links…