Based on UX feedback, improve the import wizard screens. Primarily, this means providing more context information along each step of the wizard.
Using the import wizard must be as intuitive, informative, and self-explanatory as possible.
Rather than displaying a text field and a file chooser to configure the Java home, allow the user to choose from the installed runtime JREs of the current workspace through a dropdown.
We want to provide a deep integration into Eclipse, allowing users the means to configure a JRE the way they already know.
In order to allow development of Buildship with Buildship, the import logic needs to become Eclipse plugin-aware.
- Read the JRE version from the MANIFEST file and set on the project.
- Detect if the project uses the Groovy plugin and set the Groovy nature for those projects.
Buildship should support the development of Eclipse plugins written in Java.
When importing a Gradle project that has already been imported into the workspace as a Gradle project before, override the existing configuration rather than failing with an error that the project already exists. During the re-import, detect if something has actually changed before applying the change.
It is a common scenario for users to re-import a project because its configuration has changed.
For the Eclipse Mars distribution, display the Eclipse projects of a Gradle multi-project build in a hierarchy. Have an option in the header of the Project Explorer to switch between flat view and nested view.
Displaying the Eclipse projects in a hierarchy closely reflects the Gradle project hierarchy of a multi-project build.
It should probably be possible to import only a single Gradle project from a multi-project build.
It seems a very common use case for Eclipse developers to only import part of a multi-project build.
Similar to other components like PDE or Maven, Buildship should allow to convert an existing project via the context menu of the project, i.e., Configure -> Convert to Gradle Project.
The most simple would be to add the Gradle nature to the project and to create an empty Gradle build file.
A more invested solution would be to check if the Java nature is available on the project and add the Java plug-in to the generated Gradle build file in this case. Also if the source folder follows the 'legacy' structure of Eclipse projects, a source mapping should be added to the Gradle build file.
See Bug 465355 for details on the implementation.
This development would make a migration to Gradle simpler for new users and follows the Eclipse conventions of conversions.
If available, import the buildSrc folder into the workspace as a separate Eclipse project named buildSrc.
Build authors often make use the buildSrc folder in non-trivial projects.
Provide a wizard that allows to configure the main aspects of a single-/multi-project build. Create the involved build files, configure them according to what the user has specified, and then import the newly created project into the workspace.
Inexperienced Gradle users appreciate a project creation wizard that provides an easy way to get started with a new Gradle project.