Buildship into the Future

Buildship is the official Gradle integration for Eclipse. It helps Eclipse users synchronize Gradle builds with their workspace, execute tasks without leaving their IDE and also serves as a reference implementation for how to build great IDE support for the Gradle Build Tool.

Buildship has come a long way since its inclusion into Eclipse Mars.1. The user experience has been improved significantly, with more information defined in the Gradle build being applied by Eclipse Buildship. Synchronization performance has improved by orders of magnitude. And there are exciting new features coming up, with Buildship 2.x, that will keep up your development flow even better!

Buildship 1.0.x - Polished Features

Buildship 1.0.17 is our most recent release and comes with many improved features. It is a drop-in replacement, so go ahead and update to get the following highlights.

More Accurate Project Synchronization

Our vision for Buildship has always been: “the build is the single source of truth”. Developers should not spend time manually configuring Eclipse projects. Instead, everything should just work out-of-the-box after importing a Gradle project. With each new release of the Gradle Build Tool and of Buildship, we get a step closer to realizing this vision.

As of Gradle 3.0, you will be able to configure everything about your .project and .classpath files via the Gradle DSL. This will make it possible to extract common configuration into Gradle plugins and apply them to all your projects.

Thanks to an Open Source Partnership with one of our customers, there is now initial support for Eclipse WTP in Buildship. The classpath entries of web projects are correctly categorized into deployed and non-deployed dependencies.

Improved Usability

Buildship now allows you to run single test cases through Gradle, just like you are used to with the JUnit plugin. This has the added benefit that all additional logic defined in your Gradle tasks - like setup and teardown of the test environment - is executed as part of running the tests.

In the Project Explorer, you can now choose to show or hide the build folder as well as sub-project folders. And, the Gradle synchronization can be triggered from several convenient locations, like the context menu of the build script.

By popular demand, the Buildship configuration files no longer contain user-specific paths, so you can check them into your version control system.

Performance Matters

Every time you add a dependency or change a setting in your Gradle build, you want to synchronize your workspace projects. This should not break your flow, which means it needs to be very fast. We have invested heavily into synchronization performance, to the point where our 500 subprojects example build is synchronized in less than 10 seconds. Further optimizations are still possible. The Gradle Build Tool team and the Buildship team are continuously improving workspace synchronization performance in Buildship, as well as configuration and dependency resolution performance in the Gradle Build Tool to make the import even faster.

What’s more, Buildship now caches the information collected from the build, in particular the classpath entries, such that no synchronization is needed on startup. You can immediately start working on your projects once your Eclipse workspace has started.

Buildship 2.x - Exciting New Features

For the next major upgrade, we want to further improve the developer experience beyond just project synchronization accuracy and performance. Working with multiple repositories, editing build scripts, and getting more insights into your build will be central themes of the Buildship 2.x releases.

Composite Build Support

If you work with a multi-repository setting, then you probably know this pain: there is a bug in one of your libraries, but it only occurs in one specific application. You write a fix and are ready to try it out in your application. The current state of the art is to:

• publish the library to your local repository
• update the application’s build script to consume that local artifact
• run some tests
• repeat until the bug is fixed

This is time consuming and breaks your flow.

To solve this problem, both on the command line and in the IDE, Gradle 2.13 introduced the concept of a Composite Build. It allows you to handle several distinct Gradle builds as if they were one big multi-project build. Binary dependencies are automatically replaced with project dependencies. Any changes in upstream projects become immediately visible to dependents without intermediate publishing steps.

Buildship 2.x will be the first tool to leverage the new Composite Build functionality. Buildship will automatically replace external dependencies with project dependencies. Also, it will de-duplicate project names across all builds in the workspace. Finally, any task executed in Buildship will be aware of the other imported projects and automatically build those first, if needed.

Kotlin Support

One of the most requested features for Buildship is to provide great support for editing Gradle build scripts. Unfortunately, the Groovy support for Eclipse is in an unmaintained state and therefore not something we can build upon. Thankfully, Groovy is no longer the only language available to write your Gradle build scripts in. In collaboration with JetBrains, we are embracing Kotlin as the future preferred language for writing Gradle build scripts.

The engineers at JetBrains are committed to bringing great Kotlin support to Eclipse; the plugin is already available on Eclipse Marketplace. Based on their work, Buildship will be provide a smooth editor experience for Gradle build scripts, with syntax highlighting, auto completion, code navigation, and all the other goodness you have come to expect from an Eclipse editor.

Build Scan Integration

Gradle has become a platform consisting of the Gradle Build Tool and the Gradle Cloud Services. The first available service is the Build Scan Service. Build Scans provide deep insights into your build. They allow you to understand, debug, and optimize your Gradle builds. Organizations can use Build Scans to analyse all executed builds, both on CI servers and developer machines. They allow you to make data-driven decisions about what part of the build automation to improve next.

Buildship will provide a smooth integration with the Build Scan Service, allowing you to easily create Build Scans and quickly navigate to their visual presentation. When encountering a problem, instead of painstakingly explaining your build setup, your environment, and your build issues to a colleague, you will be able to share a Build Scan that provides deep insights into your build with one single click.

Try It Now

Buildship 1.0.15 is included in several packages of the Eclipse Neon release. For the best developer experience, update to the latest 1.0.x release via the Eclipse Marketplace. To try out Buildship 2.x and the new Composite Build functionality, install the latest milestone. Make sure you are using at least Gradle 2.14 for dependency substitution to work.

Provide Feedback

We are always happy to receive feedback via the Buildship forum or reports on Bugzilla. Many of the improvements that have made it into Buildship releases were inspired by feedback from our valued community. The forum is also the place to go if there is a feature that you would like to help develop.

Accelerate the Development of New Features

Many of the great features in the Gradle Build Tool and in Buildship were developed through Open Source Partnerships. If there is a feature you would love to see in Buildship very soon and you are willing to sponsor it, please do not hesitate to reach out to us.