Buildship deeply integrates Gradle into Eclipse. But, there is always more to be done. Given that the Buildship priorities are conflicting with other development priorities at Gradle Inc., we are reaching out to our valued Community and customers to collaborate with us to realize those outstanding features. If you are interested in sponsoring any of the stories listed below, please do not hesitate to approach us.
UI to update the Gradle Wrapper
Currently the users have to manually set up a run configuration to update the Gradle wrapper from within Eclipse. Buildship could have a UI to specify the Gradle version to update to and then the Gradle wrapper task is run with that version.
Preferences API integration
Many Eclipse plugins store all their configuration in the generic Eclipse preference storage. Having an API for that in Gradle would allow build authors to customize these preferences without writing custom tasks. Gradle itself could also make use of this new facility, e.g for Java and Scala compiler settings. Buildship should consume these preferences through the Tooling API, requiring no further extensions to handle many existing Eclipse plugins.
Separation of compile and runtime classpath
Buildship currently uses the compile classpath to launch applications with JDT, resulting in class loading problems when using frameworks like Spring Boot. Fortunately, there is way to tell JDT which classpath entries should be available during runtime. Gradle could use classpath attributes to distinguish between compile and runtime dependencies. Then, Buildship could configure the JDT runtime classpath based on these attributes.
Separation of compile classpath for each source set
For the time being, Eclipse defines one compile classpath per project. As a result, there is no way to separate test and production sources. There is currently a proposal in the Eclipse community to have a validator for such scenarios based on classpath attributes. Gradle could generate these attributes from the knowledge that it already has about source sets.
Run tests in debug mode
Buildship already offers a “Run As -> Gradle Test” option, which runs a test including all necessary setup and teardown tasks. This functionality could be enhanced so users can also debug the test in Eclipse as it is executed via Gradle.
Run tasks on project synchronization
There are many use-cases where the task execution is required in order to make the IDE to function properly. For example, many web projects generate their web.xml, but the tooling needs this file to be physically present. Also, there are expensive one-off code generators like Antlr that you cannot run on every auto-build, but which need to run at least once for the project to compile. Gradle could enable users to specify tasks that are associated with the project synchronization, and expose them via the Tooling API. Buildship could then run these tasks every time the project synchronization is executed.
Run tasks on Eclipse auto-build
Many projects have small, fast code generators for which there is no dedicated IDE plugin. Gradle could enable users to specify tasks that should be run whenever Eclipse builds the project, and expose these tasks via the Tooling API. Buildship could run these tasks automatically when needed.
Partial multi-project import
When importing a Gradle build into Eclipse, Buildship sets up a separate workspace project for each Gradle subprojects. This might lead to a slow IDE experience when working on a large project. Often times, a developer only needs a handful of subprojects in the workspace to work on a feature. This can be done in two stages:
Stage 1
Buildship could let users import a subset of all projects, but should do not change anything with regard to dependencies. Thus, if the subset depends on projects that were not imported, they will have compile errors.
Stage 2
Buildship could automatically compile the non-imported projects with Gradle and replace the project dependencies with dependencies on their jars.
Automatic detection of the root project during import
When the user tries to import a Gradle project that is not a root project, Buildship fails with an error message. Instead of failing, the root project could be automatically detected and offered for import.
Eclipse “Smart Import” integration
Eclipse Neon offers a new project import wizard which automatically detects which kind of project a user selected. This will become the default wizard for SCM integrations in the future. Buildship could participate in this new wizard.
External Gradle plugins to build Eclipse plugins
Buildship is built with Gradle, based on a set of custom Gradle plugins. These Gradle plugins are currently part of the Buildship code base and not easily reusable by other projects. They could be extracted into external Gradle plugins hosted on the Gradle plugin portal. This would give Gradle users a powerful alternative to Maven Tycho to build Eclipse plugins.