Stumped by "workspace already contains a project" error

Several people (including me) have recently started using Buildship successfully. However, one person on the team can’t get his Eclipse workspace set up successfully, getting the error:

Synchronize Gradle projects with workspace failed due to an unexpected error.
Workspace already contains a project with name newton.
java.lang.IllegalStateException: Workspace already contains a project with name newton.

while doing File>Import.

In helping him, I had him create a brand new Eclipse workspace and a brand new clone of the Git repo containing the Gradle projects and he still gets the error. Before doing the Gradle import, the Eclipse project explorer showed no projects.

There’s presumably some bit of state somewhere that needs to be cleaned up, but I’m not finding it.

Does anyone have any suggestions?



1 Like

Hi Nat,

which version of Buildship are you using? Is the git checkout location physically nested inside the Eclipse workspace directory?


Hi Stefan,

Buildship v2.0.0v20170111-1029 (on Neon.2). No physical nesting.

In case it’s relevant, in an earlier configuration my co-worker did have nesting and I was sure that’s what his problem was. Actually, he had several suspect configurations, and I was sure that each one of them was the cause, but none of them were. And to make sure some old stuff in his environment wasn’t the source of his trouble I had him create a new Git clone and a new Eclipse workspace.

Also, as I mentioned, this all works fine for me but I just noticed that I’m running Buildship 1.0.21.v20161010-1640 which makes me wonder whether the problem isn’t in fact with the newer version of Buildship. I can try upgrading when I get a chance and see if the problem starts happening for me.



Okay, please keep me updated. If you can create a reproducible example that would help a lot.

Are you creating the “clean” workspace in the exact same location as before? Perhaps the eclipse cache is dirty

You can add -clean to your eclipse shortcut arguments (or add -clean to eclipse.ini) to clear the cache. Be sure to remove this after as eclipse startup is much slower

I was able to reproduce the problem in my environment and I think it does come down to a different between 1.0.21 and 2.0.0 and the fact that my source repo has version-controlled .project, .classpath, and .settings directories. (These exist for devs who are not yet using Buildship.) In 1.0.21 the import step reported the existence of these files and asked me if I wanted to overwrite them. In 2.0.0 I just get the “Workspace already contains a project” error. If I manually delete those file, the import succeeds.

The problem is likely a discrepancy between the directory name and the name in the checked in .project files. Gradle is case sensitive but depending on your file system Eclipse might treat Foo and foo the same and thus fail when we try to rename.

OK, some additional info:

  • The top-level build.gradle lives in a directory named .../newton.
  • The top-level Gradle project’s name property is not explicitly set, so I assume that property is being defaulted to newton (i.e., the last segment of the containing directory’s path name) and that Buildship is using this property to determine name of the Eclipse project that corresponds to the top-level Gradle project.
  • The pre-existing (added-to-source-control) .project file I mentioned earlier in this thread is not in the top-level directory. This .project file contains <name>newton</name>.

In short, it seems like a setup designed expressly to confuse Buildship :slight_smile: But probably Buildship should handle the situation more gracefully.

I just changed the name of the project in the pre-existing .project file to be a non-conflicting name and the import then succeeded.

That’s an interesting situation indeed, thanks for investigating the details!

@donat could we set the correct name when we include an existing project into the workspace? Currently we are first importing it (with a potentially wrong name) and later renaming it.