Announcing Buildship 2.0
Table of Contents
Introduction
We are pleased to announce that version 2.0 of Buildship—our official Gradle support for Eclipse—is now available via the Eclipse Marketplace. This release adds support for composite builds, greatly reducing development turnaround time. The UI has been redesigned based on plenty of community feedback during the 1.x line. Project synchronization is now more accurate and project import requires one less step. We’ve added support for Gradle’s offline mode (thanks Rodrigue!), and last but not least, third-party integrators can take advantage of our new InvocationCustomizer extension point. Read on for details about each of these new features.
Composite build support #
What is a composite build? #
The composite build feature in Gradle allows you to handle several distinct Gradle builds as if they were one big multi-project build. This dramatically shortens the turnaround time when you need to work on several projects that are normally developed separately.
Let’s assume you have written a Java library lib, used by many of your applications. You find a bug which only manifests itself in the special-app. The traditional development workflow would be to change some code in lib and install a snapshot into the local repository. Then you would have to change the build script of special-app to use that new snapshot and check if the bug is actually fixed.
With composite builds, however, you can tell Gradle to treat both of these projects as one. This will let special-app depend directly on the output of the lib project.
You can learn more about composite builds in this introductory blog post.
Composite builds in the IDE #
If you develop special-app you probably have it imported in Eclipse with lib referenced as a binary dependency.
There is not much difference between working with composite builds at the command line and working with them within Eclipse. To include lib you need only add an entry to your settings.gradle file, telling Gradle from which folder the additional build should be included.
includeBuild '../lib'
Then, to apply the changes right-click on the project and select Gradle > Refresh Project. After the synchronization finishes, you should see two things: the project from the included build is imported and the binary dependency is replaced with a project dependency.
Now, you can make changes to both projects with the benefit of complete IDE support: error markers, code completion, refactoring and more. Also, if you execute Gradle tests—or any other build task—from the Gradle Tasks view, the execution considers changes from the included builds.
Limitations #
When using composite builds from the IDE you should be aware of the following limitations:
- Composite builds support only works if the imported project uses Gradle 3.3 or above.
- Task execution is disabled on included builds due to a task addressing limitation in Gradle.
- Including WTP projects into a composite is not supported.
Design overhaul #
We updated the Buildship user interface to align it with current Gradle branding as well as with the Eclipse design guidelines. The icons are now distinguishable by color-blind people and work well with Eclipse’s dark theme. Finally, high-definition images have been put in place for use with High-DPI displays.
Import wizard simplification #
We removed JAVA_HOME, program arguments, and JVM arguments configuration from the import and new project wizards. Users can still configure these properties via the gradle.properties file.
More accurate project synchronization #
In Buildship 1.x if the project being imported had Eclipse descriptors then a dialog was shown to determine if those descriptors should be updated or deleted. This behavior was error-prone and distracting for users.
To avoid showing a dialog, we improved the project synchronization algorithm the following way: If the Gradle version used by the project can provide a specific attribute (e.g. project natures), it is completely overwritten. Manual modifications are only kept if Gradle provides no information about that attribute. This allows users of older Gradle versions to work around missing information in the model, while giving users of new Gradle versions a much more consistent experience.
Offline mode support #
Users can now set Buildship to work offline via the workspace preferences. Once enabled, all Gradle invocations will receive an extra --offline argument.
InvocationCustomizer extension point #
The InvocationCustomizer extension point enables Eclipse plugins to contribute extra arguments to Gradle builds. This allows integrators to add init scripts or control project properties from the IDE. For a sample implementation check out the Buildship documentation.
Breaking changes #
This release introduces the following breaking changes:
- Minimum Java version set to 1.7
- Minimum Eclipse version is set to 4.2
- Project renaming is disabled for projects that are located directly under the Eclipse workspace location.
- Projects migrating from Eclipse Mars directly to Eclipse Oxygen need to be reimported
- JAVA_HOME can no longer be configured on import, please use
gradle.propertiesinstead - Java arguments and Gradle properties can no longer be configured on import, please use
gradle.propertiesinstead
Installation #
Buildship 2.0 is available from the Eclipse Marketplace or from the eclipse.org update sites. Please note that the update site URL has changed therefore no automatic update is available for this release.