Eclipse Buildship: Eclipse Plug-ins for Gradle 1.0.3 Release Review

Current state

The Buildship project has gone through a review process with Buildship 1.0, released in July with Eclipse Mars in the new Marketplace.

Recently, Buildship has become part of the Mars and Neon release trains. Buildship has also been added to the aggregation builds of Mars 1 and Neon. Most recently, Buildship has been included in the Java package, the Eclipse Committers package, and the RCP/RAP package - for both Mars 1 and Neon.

Buildship 1.0.3 will be released time for Mars 1 with various fixes to the 1.0 release.

Working and demonstrable code base with extensible frameworks and exemplary tools

The current focus of Buildship is to be a tool for Eclipse users. This resolves the currently biggest pain point: having a solid tool to work with Gradle from within Eclipse. The framework aspect will be covered once we have a better understanding of what (if anything) third parties actually want to build on top of Buildship. We currently do not expose any public APIs.

So far, the architecture and design of Buildship has proven to be solid. The plugin works reliably and in those cases where issues are reported, we can fix them quickly and smoothly - without accumulating technical debt. We have lots of automation in place, from building to testing to deploying.

Active communities

Over the past 10 weeks, we have had about 6'500 downloads from the Eclipse Marketplace. This number does not include all those users that use snaphsot and milestone releases of Buildship.

We have an active user community. All communication between the Buildship project and the community takes place in the Gradle Forum for Buildship (https://discuss.gradle.org/c/help-discuss/buildship). This is the most natural place for Gradle users to ask any Gradle-related questions, including questions about Buildship (which sometimes turn out to be Gradle core questions). Many issues (fixes/enhancements) are reported in the Gradle Forum for Buildship, and we actively handle them - many issues being fixed within a short period of time.

We have a multi-organization community. We have an active relationship with various companies/entities; amongst them are Vogella, RedHat, Itemis, and others. They provide us with suggestions, feedback, and PRs that fix bugs and provide new functionality. We also get constant feedback from developers from the community through BugZilla and through the forum.

The project is operating fully in the open using open source rules of engagement

The source code is hosted publicly on GitHub, managed by the Eclipse organization. Discussions take place in the Gradle Forum for Buildship which is open to everyone. Issues are tracked in eclipse.org’s BugZilla which is public. Daily snapshots of master are published as public update sites on eclipse.org. All stories we intend to work on at some point in time are described in GitHub. We respond to all community input as fast as we can. We highly value input from the community.

The project team members have learned the ropes and logistics of being an Eclipse project

We have gotten excellent and very close mentorship from the beginning on from Wayne Beaton and Markus Knauer (thanks!). We adhere to the process to the best of our knowledge and feel comfortable with the process. We actively promote Buildship at conferences, either Eclipse-related events or Gradle-related events. For example, in 2015, Etienne, Buildship project lead, has spoken about Eclipse & Gradle at the Gradle Summit, EclipseCon NA, EclipseCon France, and soon at EclipseCon Europe. 

The project continues

The Buildship project team is very passionate about Buildship and Gradle, and there are many exciting things we want to do in the near and far future. Some ideas are debugging tests from within Eclipse, debugging Gradle builds from within Eclipse, having a richer model of the Gradle build available in Buildship to fine-tune the project configuration, providing more build insights by giving the user new views for plugins, dependencies, components, etc. We also want to tackle syntax high-lighting, code completion, dependency assistance, and more. Most of these stories are not yet spec'ed out or assigned to a given point in time.

We get a lot of very positive feedback for Buildship through various channels (conferences, forum posts, direct contacts, etc.). Now that we have jumped on the Mars 1 and Neon release trains, graduating out of incubation is an important next step in the process life-cycle of Buildship.