Buildship: From Inception to Inclusion in Eclipse
At Gradle, we believe that maintaining developer “flow state” is essential to building good software. And because we believe flow is essential, we assert that developers should not have to leave the IDE to build, and they should not have to know what functions are being performed by the IDE and what is delegated to the build system. It is also our vision that all build logic is kept exclusively in the build system and thus all work to calculate the project configuration, to build the project, to run the tests and to run an executable is delegated from the IDE to the build system. Hence the IDE maps the projects of the build, visualizes the build models, and displays the progress of executing a build.
To realize our vision of ideal IDE Gradle interaction, we resolved to build and offer our own reference implementation to guide implementers of other IDEs. Because of this, in the Fall of 2014, Gradle Inc. decided to provide its own Eclipse plugin for Gradle to give the users the best experience when working with Gradle from within Eclipse.
Buildship invited to join the Eclipse Mars release train
Soon after we had started with the implementation, the Eclipse Foundation asked us whether we would like to contribute an Eclipse plugin for Gradle and have the plugin become part of the Eclipse Mars release train. This fit well with our vision for demonstrating how IDEs and builds should interact and further allowed us to serve the large global group of Eclipse users with the best Gradle support possible. We agreed and the project onboarding process defined by eclipse.org started immediately.
Our first step was to find a name independent of either Gradle or Eclipse and get it trademarked, thus the Buildship project was born and made official. The suffix “ship” has a nice feel, denoting condition, character, office, skill such as “Fellowship” or “Statesmanship”, but also emphasizes the significance of shipping software. From the very beginning, Wayne Beaton from the Eclipse Foundation assisted us with all the countless steps involved in the formal process of going from a project without a name to a project that is part of the Eclipse Simultaneous Release.
Gradle builds Eclipse bundles
On the implementation side, in January 2015, we started by creating a Gradle build to compile, test, assemble, and deploy Eclipse bundles. No satisfying solutions existed that we could leverage. The work on our own new build was very incremental and the buildSrc feature of Gradle proved very valuable to quickly mature our build logic. Today, our build is very stable, its logic is packaged into Gradle plugins defined in the buildSrc folder, and the plugins are generic enough to be used by other Eclipse bundle projects. Looking at the advanced logic of our Gradle build, there is no way we could have achieved the same conciseness and expressiveness with Maven, which is still ubiquitous for Eclipse bundle projects.
Buildship debuts at EclipseCon NA in March
Once the Gradle build was established and a Continuous Integration pipeline set up on top of it, we were able to start focusing on the content of the Eclipse plugin for Gradle. We started with the Tasks View, took on the Project import, added Run Configurations and a Console View, and then integrated into the existing Eclipse Test Runner. This was the state that we presented at EclipseCon NA in March 2015.
Gradle dedicates more developers to Buildship
To accelerate the development of Buildship and to ensure that we would meet the deadline for the Eclipse Mars release in June 2015, we got Simon Scholz from Vogella GmbH to help us with work that required in-depth Eclipse knowledge, which proved to be invaluable. We also dedicated one more Gradle core developer to work on Buildship. Replacing our integration into the Eclipse Test Runner with our own Executions View was next. This view visualizes what happens when running a build, like what tasks are run, what tests are executed, and so on. The visualization happens based on events that Buildship receives from Gradle via the Tooling API. The Tooling API is a separate, standalone Gradle library with its own API that allows the IDE to communicate with a Gradle build through inter-process communication. The architecture where the Tooling API serves as a proxy of the Gradle build comes with many advantages, like process isolation, backward/forward compatibility, and contained build logic. Many enhancements have been added to the Tooling API during the development of Buildship, like event broadcasting, optimized classpath dependency calculation for Eclipse, and more.
Buildship released simultaneously with Eclipse Mars at EclipseCon France in June
With the Task View, the Executions View, the Console, View, the Run Configurations, and the Project Import Wizard in place, we were ready to become part of Eclipse Mars. Unfortunately, not everyone was convinced that we were ready yet to become part of the Simultaneous Release and so in June 2015, we shipped Buildship on the same day with Eclipse Mars but not yet in Eclipse Mars. The Eclipse Foundation had created a new entry in the Eclipse Marketplace for that purpose with a select few plugins hosted there. This allowed all users to select and install the Buildship plugin right from within Eclipse. This was the state that we presented at EclipseCon France in June 2015.
Gradle continues to invest in Buildship features based on your feedback
After the release, the work on enhancing Buildship continued without interruption. We focused on enhancing and polishing the existing functionality, primarily based on feedback we had received through our Buildship Forum. The Forum is actively used to report issues, to request new features, and to ask questions. One topic that came up repeatedly was to extend the import functionality and to allow the user to explicitly refresh imported projects. Thus, we invested a significant amount of work into consolidating and at the same time extending the logic of importing a project, explicitly refreshing a project, and opening a project. We also added a new feature that allows a user to execute tests through Gradle from the Executions View and from the Source Editor. This is the state that we will present at EclipseCon Europe in November 2015.
Community tracks and fixes a mysterious bug
In time for Eclipse Mars.1, we finished our enhancements, became part of the Simultaneous Release, were included in three important Eclipse distributions (EPPs), and the Buildship project itself graduated out of incubation to become a full project. Due to a bug that was found in Buildship during the quiet period of the Mars.1 release, we had to provide a new version of Buildship that delayed the final Mars.1 release by one week. The bug had been there since June but nobody had ever made the connection before between how the bug manifested itself and Buildship being the plugin causing the problem. The severity of the bug and how to go about fixing it were discussed and resolved openly on the Eclipse Mailing List.
Buildship released in Eclipse Mars.1
On October 2nd, 2015, Eclipse Mars.1 was officially released with Buildship being the most prominent new feature in the release. Developing Buildship over the past ten months has been very interesting to everyone involved since it included working on Gradle core, on the Tooling API, on Buildship itself, and participating in the eclipse.org formal process.
Even more to come
The work on Buildship will continue. We want to bring much more of our vision on how the IDE should integrate with Gradle to reality: visualizing detailed information about the rich model behind a Gradle build, supporting the project configuration for web applications, debugging tests and web applications, code assistance, and more.
Try it now
The easiest way to try out Buildship is to download Eclipse Mars for Java developers, and choose File > Import… > Gradle Project and point to an existing Gradle Java project. Let us know if you experience build happiness (or some other sensation) while working with Buildship.