Today, we have released Buildship 1.0.10, which marks our biggest release since the inclusion of Buildship in Eclipse Mars.1. The new release brings faster startup, sharable configuration, and enhanced project synchronization.
Most of the addressed issues and enhancements were reported by our valued users from the community on our Forum, through BugZilla, and via the Automated Eclipse Error Reporter. We would like to thank everyone of the Gradle and Buildship community for their valuable feedback.
We are very excited about this release and would love to hear from you how we can make Buildship even better.
Please see BugZilla for the complete list of all issues addressed in this release.
Faster startup
Buildship now persists the classpath of each project between Eclipse sessions. Thus, you no longer have to wait for classpath synchronization and incremental build to complete during startup. Instead, you can get working right away.
Buildship will only perform synchronization between Gradle and Eclipse when explicitly requested by the user via Refresh or Import.
Sharable configuration
Buildship’s configuration files have become sharable since they no longer contain absolute paths. As a result, you can now check in the configuration files to version control and simply use wizards like “Import Existing Project” or “Import Project from SCM” to have a running project.
To benefit from the new configuration file format in existing projects, just use the “Refresh Gradle Project” action and Buildship will take care of migrating your configuration files to the new format.
Generated sources visible in build folder
If the build folder of your project contains generated sources, they will now be picked up and compiled correctly. The contents of the build folder are marked as derived, so they will not show up in any search dialogs by default, and you will get a warning when trying to edit them.
The build folder is hidden from the user interface by default. You can make the folder visible in the filter preferences of the Project Explorer, Package Explorer, or Navigator.
Execution Environment set based on Source Compatibility
Buildship correctly sets the execution environment on each project’s classpath to match the sourceCompatibility specified in the Gradle build. If that execution environment has no compatible VMs yet, Buildship will register the VM that invoked the Gradle build.
Classpath container always added
Buildship always adds the Gradle dependencies to the classpath of Java projects, even if they already contained a .classpath file before. If you don’t want Gradle-managed dependencies for any reason, you can use the following snippet in your build script to empty the classpath container:
apply plugin: ‘eclipse’
eclipse.classpath.plusConfigurations = []
Support for symlinks
Buildship will now correctly handle projects inside symlinked locations.
STS Migration Guide
If Buildship detects that the STS Gradle Plugin is also installed, it will display a migration guide. The migration guide features a detailed comparison of STS Gradle and Buildship as well as the steps needed to convert your projects.
Installation
Buildship 1.0.10 is available at the Eclipse Marketplace or at the eclipse.org update sites. Users with Buildship already installed can automatically update to the latest version.