skip to content

GradleConnector and ProjectConnection

Opening a ProjectConnection with GradleConnector, choosing the distribution or Gradle version, and closing the connection properly. The entry point for any Tooling API answer.

on this pageshow

questions

5

What is the Gradle Tooling API's GradleConnector, and how do you obtain a ProjectConnection from it?

level: juniorimportance: must knowfreq 45%

answer

  1. newConnector() factory
  2. forProjectDirectory required
  3. connect() -> ProjectConnection
  4. build runs in daemon, separate JVM
  5. ProjectConnection is Closeable

basics

~10 s

GradleConnector is the Tooling API entry point. Call GradleConnector.newConnector(), point it at a project with forProjectDirectory(dir), then connect() to get a ProjectConnection you use to run or query the build.

solid answer

~40 s

The Tooling API lets a non-Gradle program (an IDE, a CI tool, a custom launcher) embed Gradle and drive builds in another process. `GradleConnector` is its factory: `GradleConnector.newConnector()` returns a fresh connector you configure, most importantly `forProjectDirectory(File)` to say which project to connect to. Calling `connect()` returns a `ProjectConnection`, the handle through which you actually do work — build a model, launch tasks, run tests. The connector spins up (or reuses) a Gradle daemon and the build runs in that separate JVM, so your tool stays isolated from the build's classpath. A `ProjectConnection` holds resources (the daemon connection), so it is `Closeable` and must be closed — typically with try-with-resources.

code

java · 9 lines
java
import org.gradle.tooling.GradleConnector;
import org.gradle.tooling.ProjectConnection;
import java.io.File;

try (ProjectConnection connection = GradleConnector.newConnector()
        .forProjectDirectory(new File("/path/to/project"))
        .connect()) {
    // run tasks, build models, etc.
}

go deeper

for a junior

Name GradleConnector.newConnector(), forProjectDirectory, connect() returning a ProjectConnection.

for a middle

Add that the build runs in a daemon in a separate JVM and ProjectConnection is Closeable.

for a senior

Discuss distribution selection (useGradleVersion vs useInstallation vs useBuildDistribution) and resource lifecycle.

for a principal

Frame it as the embedding contract IDEs/CI rely on, and how isolation and daemon reuse affect tooling architecture.

## What the Tooling API is The **Tooling API** is a Java client library that lets an external program embed and control Gradle without shelling out to the CLI. IDEs (IntelliJ IDEA, Eclipse Buildship) use it to import projects, run tasks, and fetch build models; you can use it to script builds programmatically. The build does **not** run inside your process. The Tooling API connects to a **Gradle daemon** (a long-lived background JVM) and the build executes there. This keeps your application's classpath isolated from the build's, and lets the daemon cache state across invocations. ## The entry point: GradleConnector `GradleConnector` is the factory. The flow is always: 1. `GradleConnector.newConnector()` — create a connector. 2. Configure it: which project, which Gradle distribution. 3. `connect()` — returns a `ProjectConnection`. 4. Use the `ProjectConnection` to do work. 5. `close()` the connection (and optionally `disconnect()` the connector). ### Pointing at a project `forProjectDirectory(File projectDir)` is required — it names the directory containing the build you want to drive. ### Choosing the Gradle distribution By default the connector downloads/uses a Gradle version it picks. You usually override that: - `useGradleVersion("8.7")` — download and use a specific version. - `useInstallation(File gradleHome)` — use an existing local Gradle install. - `useDistribution(URI)` — use a distribution at a URL. - `useBuildDistribution()` — use the version the project's wrapper declares (honor the wrapper). ## ProjectConnection `ProjectConnection` is the working handle. From it you obtain the other Tooling API operations (model builders, build launchers, test launchers — covered by sibling topics). It implements `Closeable`; failing to close it leaks the daemon connection. ```java try (ProjectConnection connection = GradleConnector.newConnector() .forProjectDirectory(new File("/path/to/project")) .connect()) { // use connection here } ``` ## Mental model Think of `GradleConnector` as `DriverManager` and `ProjectConnection` as the JDBC `Connection`: a factory you configure once, producing a resource-holding handle you must close.

  • Does the build run inside your application's JVM?
    No. The Tooling API connects to a Gradle daemon and the build runs in that separate process, isolating your classpath from the build's.
  • What is the minimum you must configure before connect()?
    The project directory via forProjectDirectory(File). Everything else (Gradle version, args) has defaults.

GradleConnector is like JDBC's DriverManager and ProjectConnection is like the Connection it hands you — configure the factory, get a resource-holding handle, close it when done.

saying these in an interview costs you the question

  • Saying the Tooling API runs the build in your own process
  • Forgetting that ProjectConnection must be closed

context

open as a page

Why must a ProjectConnection be closed, and what is the idiomatic way to ensure that happens?

level: middleimportance: must knowfreq 40%

basics

~10 s

ProjectConnection implements Closeable and holds a connection to the Gradle daemon. If you do not close it you leak resources. Use try-with-resources so close() runs even on exceptions.

open as a page

How do you control which Gradle distribution a GradleConnector uses, and when would you choose each option?

level: middleimportance: should knowfreq 35%

basics

~10 s

On the connector: useGradleVersion("8.7") downloads a version, useInstallation(dir) uses a local install, useDistribution(uri) uses a URL, and useBuildDistribution() honors the project's wrapper. Pick based on reproducibility needs.

open as a page

Beyond the project directory and distribution, what connection-level settings can you configure on a GradleConnector or ProjectConnection, and how?

level: seniorimportance: should knowfreq 25%

basics

~20 s

On the connector you can set the Gradle user home with useGradleUserHomeDir(File). Per operation (via the ProjectConnection) you set JVM args, build args, environment, JAVA_HOME, stdout/stderr and cancellation through the LongRunningOperation methods like setJvmArguments and withArguments.

open as a page

How should a long-running host (like an IDE) manage GradleConnector and ProjectConnection lifecycles across many operations?

level: seniorimportance: nice to knowfreq 18%

basics

~20 s

A single ProjectConnection can run many operations, so reuse it per project rather than opening one per task. Open lazily, keep it while the project is open, and close it when the project closes. Daemons are pooled and reused underneath.

open as a page