Confusing error when renaming project

Help/Discuss Buildship
1

I had a Gradle project in my workspace that I wanted to rename. It is not associated with SCM yet. When I executed the rename (from “estimator” to “estimatorold”), I got an error dialog that said this:

    org.eclipse.buildship.core.UnsupportedConfigurationException: Project at '...\estimatorold' can't be named 'estimator' because it's located directly under the workspace root. If such a project is renamed, Eclipse would move the container directory. To resolve this problem, move the project out of the workspace root or configure it to have the name 'estimatorold'.
    at org.eclipse.buildship.core.workspace.internal.DefaultWorkspaceOperations.validateProjectName(DefaultWorkspaceOperations.java:183)
    at org.eclipse.buildship.core.workspace.internal.ProjectNameUpdater.checkProjectName(ProjectNameUpdater.java:107)
    at org.eclipse.buildship.core.workspace.internal.ProjectNameUpdater.updateProjectName(ProjectNameUpdater.java:44)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeOpenWorkspaceProject(SynchronizeGradleBuildOperation.java:194)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeWorkspaceProject(SynchronizeGradleBuildOperation.java:182)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeGradleProjectWithWorkspaceProject(SynchronizeGradleBuildOperation.java:172)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.access$000(SynchronizeGradleBuildOperation.java:99)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation$1.run(SynchronizeGradleBuildOperation.java:134)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2262)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeProjectsWithWorkspace(SynchronizeGradleBuildOperation.java:131)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.run(SynchronizeGradleBuildOperation.java:115)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(SynchronizeGradleBuildsJob.java:81)
    at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(SynchronizeGradleBuildsJob.java:72)
    at org.eclipse.buildship.core.util.progress.ToolingApiJob$1.run(ToolingApiJob.java:73)
    at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:62)
    at org.eclipse.buildship.core.util.progress.ToolingApiJob.run(ToolingApiJob.java:70)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
2

So I noticed that the “settings.gradle” file was setting the root project name, and after the project rename, it still had the old name. Once I changed that name to the new name and refreshed the project, that error went away.

Ideally, I would expect a project rename would fully perform the refactoring steps required to effect that rename, including changing the setting of the root project name in the settings.gradle file. I can understand why a general solution for that could be complicated, as the file is a Groovy script, which would have to be fully parsed to determine what value to change, and the value could potentially be an expression, not just a simple value (not very likely, however). However, in the vast majority of cases, that file will be pretty simple, and the setting of that pretty simple.

Failing a proper refactoring solution, wouldn’t it be better if the error message was a little more explicit about what exactly needs to be done (referring to the project name setting in the settings.gradle file)? It also doesn’t really need to present a stacktrace (although I would expect that would go into the log).

3

Open your settings.gradle file. At the bottom you should see something like “rootProject.name = ‘TheNameOfYourProject’” Rename the folder that contains your project to TheNameOfYourProject and try to reload it

4

This would be a really nice feature indeed. But if you think about it, we’d have to implement full editor and refactoring support to resolve that. Since the Groovy support for Eclipse is in maintenance mode, we’d need to find a different solution and potentially reimplement the whole language tooling. Given that there’s a simple workaround (use an external folder for your projects) I doubt that the benefits would justify the investment. Besides, there are much more pressing issues in Buildship that our users need (task execution upon synchronization, elaborate preferences, build scan support, dependency scope support, just to name a few).