Buildship 1.0.5 contains a fix for a critical bug: once a Gradle task has been launched from the Tasks View, the user will not be prompted for the workspace anymore the next time he starts Eclipse, but instead the very default Eclipse workspace is used. This problem might only be apparent conditionally.
Buildship 1.0.5 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. Buildship 1.0.5 will also become part of the Mars 1 distributions.
In case the problem described above persists after the update, please try to do a clean startup. To do that, close the running Eclipse instance and start it with the following command:
I recently updated my Buildship version to 1.0.5 in Eclipse, then deleted all projects in the Eclipse workspace, then imported my projects again with Buildship. Now I could see: Buildship doesn’t change the .classpath anymore (as created by Eclipse and stored in our SCM). In my environment, this means: all 3rd Party jars still will be resolved with what we have without Gradle: all needed jars come from some special designated file directory.
This is not what I expect from Gradle enabled projects in Eclipse; instead, I would prefer to have the classpathes point into the Gradle cache. One of our goals with Gradle and Eclipse is to have a common dependency management.
Former versions of Buildship created it’s own .classpath files; inside, they defined some classpath container (which hides Gradle cache). Has this gone? Or am I doing something wrong?
Notice, before using Buildship, we tried to import our projects into Eclipse after we ran the Gradle eclipse task on them. So we had classpathes pointing into the gradle cache.
Oh yeah, I was confused, because I didn’t remember that it is best to delete all existing Eclipse .classpath files and .project files when you import projects as Gradle project. Buildship will generate those files completely new.
I think it would be a good idea to tell this new users in your overview docs.s
Specifying the import behaviour depending on the existence of the project descriptors indeed belongs to the user documentation. For that I added an entry to our backlog.