Spring Tools: one Spring layer delivered as VS Code, Cursor, Eclipse and Theia extensions

One Spring layer across four different host editors

Spring Tools is described as the next generation of tooling for Spring Boot, and the repository description names the scope beyond the editor itself: support for Cloud Foundry manifest files, Concourse CI pipeline definitions and BOSH deployment manifests, among other things.

The delivery model is what distinguishes it. The same Spring tooling arrives through several channels depending on where you already work. There are extensions for Visual Studio Code, for those who prefer that lightweight editor. There are extensions for Cursor, described as the lightweight editor for agentic development. There is a Spring Tools plugin for Claude Code, which the README says brings more Spring smartness to Claude. There is a Spring Tools for Eclipse distribution, a ready-to-use build of the latest Eclipse Desktop IDE prepackaged with Spring Tools and a few additional third-party extensions, which you download, unpack and start. There are Spring Tools for Eclipse extensions, installable into an existing Eclipse Desktop IDE. And there is Eclipse Theia, where the same extensions can be installed into Theia based environments such as gitpod.

That last pair is the interesting one for teams. The same Spring capability is available whether you own your IDE installation or work in a cloud workspace that appears and disappears.

Documentation lives in the project wiki, with detailed installation instructions in the installation wiki and the user guide, and general questions are asked on StackOverflow with the spring-tools tag. The project publishes updates on X and on Bluesky.

The repository is a monorepo of several deliverables

The top-level layout explains how the pieces relate to each other, and it is worth reading before you expect a single build.

There is a vscode-extensions directory, an eclipse-extensions directory and an eclipse-distribution directory, which correspond to the three delivery shapes named in the README. Alongside them sit eclipse-language-servers, headless-services and nodejs-packages, plus a claude-plugins directory and a .claude directory for the Claude Code integration.

Two other directories suggest how the build treats its own output. There is a self-extracting-jar-creator directory and an eclipse-distribution directory, and the README describes the Eclipse distribution as something you download and unpack, which is consistent with producing a self-contained archive rather than an installer. A local-build.sh script at the root and a README-dev-env.md document the development environment for working on the project itself.

There are also repository hygiene scripts worth noticing: nohttp.sh and nohttp-whitelist.txt, which is the pattern used to fail a build that introduces plain http URLs, plus fix-copyright.sh and a java-copyright-header.txt, which together enforce the copyright header on Java sources. These are small signals, but they say something about how the build treats external references and header consistency across a large multi-module tree.

Cloud Foundry, Concourse and BOSH files are first-class inputs

Most editor support for a framework stops at the application source. The Spring description goes further, and the listed artefact types are the ones a Spring Boot application actually reaches in production.

Cloud Foundry manifest files are the deployment descriptor for a Cloud Foundry application, where the application manifest lists services, buildpacks and instances. Concourse CI pipeline definitions are YAML pipeline files that describe a build and deployment pipeline. BOSH deployment manifests describe how a release is deployed, with jobs, packages and properties.

For an engineer whose day is split between writing a controller and writing the manifest that ships it, editing those files with schema-aware assistance is worth more than a nicer code completion view. It also means one editor can cover both halves of the workflow.

The caveat is that the README does not enumerate the individual features available for each of these file types, and the repository listing does not include per-feature documentation beyond the wiki links. So the honest claim is that the tooling covers these artefact types, and the fine detail of what it validates or completes has to be checked in the user documentation or by trying it against a real manifest.

Choosing between the Eclipse distribution and existing Eclipse installs

The two Eclipse options look similar in the README list and are genuinely different decisions.

The Spring Tools for Eclipse distribution is a ready-to-use distribution of the latest Eclipse Desktop IDE, prepackaged with Spring Tools and a few additional third-party extensions. You download it, unpack it, and start. The value is a known-good combination: the Spring tooling and a small set of supporting extensions, assembled by the project, with no decisions to make about which version of which plugin pairs well.

The Spring Tools for Eclipse extensions go into an Eclipse Desktop IDE installation you already have. The value is keeping your existing IDE configuration, which for many organisations means a curated extension set, corporate settings and possibly a managed build. The cost is that compatibility is now your problem, since a mismatched extension set in an existing Eclipse produces failures that are hard to trace back to a version conflict.

The realistic failure mode here is mixing the two. A team that installs the distribution and then adds another IDE on top of it, or that carries the extensions into a shared environment also used by people on the distribution, ends up with two configurations of the same tooling and no clear answer to which one is authoritative.

Neither choice is wrong in isolation. The distribution suits a team that wants a working combination quickly. The extensions suit a team whose Eclipse configuration is already a governed asset.

Release naming that splits between two product lines

The release list is where the project reveals something about its structure, and it is easy to misread.

Three releases are listed. Two are Eclipse-flavoured versions, 5.4.0.RELEASE published on 2026-09-09 and 5.3.0.RELEASE on 2026-07-29. The third is a VS Code extension, vscode-spring-boot-2.4.1-RC1, published on 2026-10-16, and its tag carries the Eclipse-style version 5.4.1.RELEASE alongside it.

So the same repository publishes two numbering schemes at once, with the VS Code extension carrying a version of its own, 2.4.1, and also being associated with a 5.4.1 release label. That is a direct consequence of the monorepo layout: the VS Code and Eclipse artefacts are separate deliverables built from one source tree, and each has its own release cadence.

The practical consequence for an adopter is that the version you see in the marketplace for VS Code is not the number that appears in the Eclipse release notes. When you write documentation, a support request or a build pipeline, name the artefact and its own version rather than referring to the project version, because the numbers do not line up.

The repository is not archived and the last push was on 2026-10-19, one day before the release of the VS Code release candidate on 2026-10-16, so the monorepo is being worked on actively across its branches.

Where to look for help, and what the licence implies

Support and contribution routes are laid out in the README, and they are worth knowing before you hit a problem.

General questions go to StackOverflow with the spring-tools tag. Bugs go to GitHub issues. The contributing guide is CONTRIBUTING.adoc in the repository, and the project operates under the Spring code of conduct. Security vulnerabilities are reported through the Spring security policy rather than through public issues, which is the arrangement the README points to for reporting security vulnerabilities.

The licence is EPL-1.0, recorded as such for the project, with the licence text in the license.txt file at the repository root. That is a more demanding licence than the permissive options, and for an organisation that ships its own distribution of the tooling it is the detail to read carefully. EPL terms are typically framed around distribution of modified versions and the licensing of the covered work, and this article gives no legal advice, so the file itself is the reference.

The plugin for Claude Code is worth a specific note for anyone with an agentic workflow. The README presents it as bringing more Spring smartness to Claude, and the repository carries a dedicated claude-plugins directory and a CLAUDE.md file. That suggests the Spring context is delivered to the assistant as part of the plugin rather than as ad-hoc prompting, which is a different integration model from the editor extensions.

Editorial conclusion

Adopt Spring Tools when your team is standardising on Visual Studio Code, Cursor or a Theia based environment and wants Spring Boot support without moving to a full Eclipse distribution, and when you edit Cloud Foundry, Concourse or BOSH manifests as part of your deployment flow. Skip it if your organisation has already committed to the Spring Tools for Eclipse distribution with its own curated extension set, since mixing the two produces conflicting editors. Before adopting, read the installation wiki for your host, check whether the release you pull in is the vscode-spring-boot line or the Eclipse line, and confirm that the EPL-1.0 terms fit your distribution model.

Frequently asked questions

Official sources

1. License: EPL-1.0
2. Project website
3. README
4. Releases
5. spring-projects/spring-tools on GitHub