Announcing Buildship 2.0
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
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.
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.
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.
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
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
InvocationCustomizer extension point
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.
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
- Java arguments and Gradle properties can no longer be configured on import, please use
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.