# Eclipse Buildship: bringing Gradle into the Eclipse IDE > Buildship is the Eclipse plug-in set that gives the Eclipse IDE a Gradle view, task runner and project import, implemented as a family of OSGi bundles. It is old enough to support Eclipse 4.2, it is licensed EPL 1.0, and it publishes no GitHub releases, so its upgrade path runs through the Eclipse update site rather than a tagged artifact. **eclipse-buildship/buildship** — The Eclipse Plug-ins for Gradle project. - Repository: https://github.com/eclipse-buildship/buildship - Stars: 549 · Forks: 176 - Language: Java - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/eclipse-buildship-buildship ## A Gradle task view inside an Eclipse workspace Eclipse Buildship exists to remove a specific friction: a team whose build is Gradle but whose IDE is Eclipse. Without an integration, the Gradle build is a separate command line tool with its own output, and the IDE view of the project drifts from what the build actually does. Buildship is the Eclipse Plug-ins for Gradle project, and its job is to make the Gradle build a first-class citizen inside the IDE workspace. The surface it adds follows from the Gradle model. Gradle is task based, so the integration is a task view where the tasks of a project can be seen and run. Gradle is a multi-project build tool, so there is project import and a way to see the project hierarchy. Gradle also carries properties that feed into the build, and Buildship contributes editors for those properties, which is visible in the repository as dedicated bundles for the property language service and the property provider. The audience is Eclipse users with Gradle builds, which in practice means enterprise Java shops and Eclipse-based toolchains, plus contributors who want to read the implementation of an IDE integration rather than only use it. ## Dozens of bundles, one plug-in set The repository layout is the clearest description of the architecture, and it is unusually granular. Instead of a single Gradle project, the top level holds a long list of separate modules, each with its own build.gradle and its own set of test bundles, for example org.eclipse.buildship.core, org.eclipse.buildship.core.test, org.eclipse.buildship.ui and org.eclipse.buildship.ui.test. Each feature area has the same shape of a bundle, a matching test bundle and a feature project that packages it. There are separate feature projects for the Gradle properties tooling, for the Kotlin DSL, for Declarative Gradle and for Oomph integration, alongside a branding project and a site project that produces the update site. A Gradle plugin, org.gradle.toolingapi, is vendored inside the repository, and there is a compat module, which suggests the code carries explicit handling for older Eclipse or Gradle API versions. There is also a samples directory with a custom-tapi-model sample and an oomph-setup sample, and a Launch Buildship.launch file, so a developer can start the plug-in development environment with the right configuration. The build itself is driven by Gradle, with a gradlew wrapper committed to the repository and a settings.gradle, a gradle.properties and a version.txt holding the version. ## The documentation is split three ways on GitHub All Buildship documentation is hosted in the repository itself rather than on a separate documentation site, and it is divided by audience. The README points to three specific guides: ```bash - [User documentation](docs/user/README.md) (plugin installation, current functionality) - [Developer documentation](docs/development/README.md) (development environment setup) - [Build documentation](docs/pluginbuild/README.md) (building Eclipse projects with Gradle) ``` There is a fourth pointer, an outline of upcoming stories in docs/stories/README.md, which is where planned work is described. The division matters when you are evaluating the project. A user deciding whether to install wants the plugin installation and current functionality guide. A contributor wants the development environment setup. A maintainer building the Eclipse artifacts wants the plugin build guide, which is the one that explains how the bundles become features and a site. One caveat on reading these as a set: the README notes that all documentation for users and developers is hosted on GitHub, and it also links the same repository pages for discussions, so the docs and the issue tracker live together. If a document is older than the code around it, the repository offers no versioning scheme for the documentation to make that visible. ## Eclipse 4.2 baseline and Gradle version coupling The requirements section is short and unusually candid about its limits. Buildship can be used with Eclipse IDE 4.2.x or newer, and the README states plainly that older versions of Eclipse might work but have not been tested explicitly. It also states that depending on the version of Gradle that Buildship interacts with, certain features of Buildship may not be available. That second sentence is the one to sit with. The integration is not a static adapter, it is version aware on both sides, and the support matrix has two axes. An Eclipse that is a decade old still nominally qualifies, which tells you the plug-in is careful about not breaking older workspaces, but it also means the feature set you get depends on the Gradle version in your build, not just on the plugin version you installed. Practically, this means upgrade decisions cannot be made on the plugin version alone. If your build moves from one Gradle major version to another, the set of Gradle features exposed inside Eclipse can change, and the documentation does not publish a matrix telling you which features belong to which Gradle version. You find that out from the user documentation and from the behaviour you see in the IDE. ## Declarative Gradle is flagged as a preview The first thing the README shows, above the requirements, is a tip box announcing a preview of Declarative Gradle support, with a link to docs/user/DeclarativeGradle.md for the setup instructions. Two things follow from the wording. First, the feature is presented as a preview rather than as shipped behaviour, and the presence of a dedicated provider bundle, org.eclipse.buildship.dcl.provider, alongside its feature project, org.eclipse.buildship.dcl.feature, confirms that it is a distinct and still emerging area of the plug-in set rather than a settled feature of the core. Second, the setup is documented separately. Declarative Gradle is not enabled by default in the ordinary installation path, it needs its own configuration steps, and the repository carries a separate stories document for what is planned next. If you are evaluating the plug-in for a build that is moving toward declarative Gradle, the relevant question is what the preview currently supports and what the stories document lists as still open, and both live under docs/ rather than in the README. ## GitHub issues with a ZenHub board for priority Issue handling is described in a few lines and it is worth knowing that the priority signal is not on GitHub itself. Issues are tracked on GitHub, and the README asks readers to add a thumbs up reaction to the issues they care about so the maintainers can prioritise them. For following the priorities and progress in more detail, the README points to the ZenHub browser extension and a board linked from the repository. So the workflow is a two step one. A reaction on the GitHub issue expresses demand, and the ZenHub board expresses what the maintainers have decided to do about it. A contributor should expect to read the board before picking up an issue, because a thumbs up is a vote rather than a commitment. The project also asks for feedback on the Gradle forums, where Buildship topics are discussed, and it does so in a fairly open way, saying the maintainers are very interested in feedback from the Gradle and Eclipse communities. For a large user base this split means GitHub issues are where defects get filed, the forums are where design questions get argued, and the ZenHub board is where the ordering is visible. ## EPL 1.0 and an upgrade path without tagged releases Buildship is available under the Eclipse Public License, Version 1.0. That licence is a business-friendly one for a plug-in, since it allows distribution as part of a larger work and does not carry the copyleft obligations of the GNU licences, while still requiring that changes to the licensed code itself stay under the same terms and that the notice travels with it. A company shipping an Eclipse-based product can therefore include Buildship in an Eclipse distribution, and a company modifying Buildship has a clear obligation about what it owes back. The README states the licence directly. The upgrade story is the part that catches people out. The repository has no GitHub releases, so there is no tagged artifact to download and compare against, and the last push was on 2026-09-23. Distribution runs through the Eclipse plug-in and update site mechanism, with a site project in the repository, which is the conventional route for a plug-in that ships with an Eclipse platform. The practical consequence is that your version is tied to whatever update site your IDE points at, and pinning a specific Buildship build is a platform configuration task rather than a version string in a dependency file. ## Conclusion Adopt Buildship if your team maintains Gradle projects and needs them in an Eclipse-based toolchain, especially alongside the Oomph and Gradle property tooling that shares the same repository. Do not adopt it as a general Gradle wrapper, for projects that need IDE features newer than the plugin's Gradle support, or if you need a pinned, auditable plugin version from tagged releases, because the project publishes none. Verify first that the plugin version you install in your Eclipse matches the Gradle version your build uses, since the documentation states that certain features depend on the Gradle version in play, and read docs/user/README.md before your first import. ## FAQ ### What Eclipse version does Buildship require? Buildship can be used with Eclipse IDE 4.2.x or newer. The README notes that older versions of Eclipse might work but have not been tested explicitly. ### How do I install the Buildship Gradle integration in Eclipse? The plugin installation steps are in the user documentation, which is hosted in the repository at docs/user/README.md along with a description of the current functionality. The README does not list the installation command itself. ### Does Buildship support Declarative Gradle? A preview of Declarative Gradle support is available, and the README links the setup guide at docs/user/DeclarativeGradle.md. It is presented as a preview rather than a finished feature, with its own provider and feature bundles in the repository. ### What licence is Eclipse Buildship released under? Buildship is available under the Eclipse Public License, Version 1.0 The repository publishes no GitHub releases, so versions are distributed through the Eclipse update site. ### How are Buildship issues prioritised? Issues are tracked on GitHub, and the README asks you to add a thumbs up reaction to the issues you care about. Priorities and progress are visible on the ZenHub board linked from the repository. ## Sources - [eclipse-buildship/buildship on GitHub](https://github.com/eclipse-buildship/buildship) - [Issues](https://github.com/eclipse-buildship/buildship/issues) - [README](https://github.com/eclipse-buildship/buildship/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-buildship-buildship