Community
Participate
Working Groups
Build: I20041102 If you checkout a project from CVS, and give the project a different name from the one in the .project file, then the .project file name will be changed as soon as the project description changes. It should instead preserve the same name in the .project unless the project is explicitly renamed.
John, do you know what is the reason for persisting project name in the .project file? As far as I checked this information could be generated on the fly. Moreover seems like the persisted value is ignored. After changing the name manually (in .project) and starting Eclipse the change is not visualized and resources API returns the old name, not the persisted one. Can other components relay on the fact that the project name is persisted? In such case it could be a bug that the value returned from the API and the one persisted are not kept in sync.
> John, do you know what is the reason for persisting project name in the .project file? It's mainly used by import tools so they can guess the name of the project when importing or checking out an existing project. For example if you use the "import existing project" wizard it will use the name in .project for the project name. > Can other components rely on the fact that the project name is persisted? Yes. If they call IWorkspace.loadProjectDescription(InputStream), they can expect to get back a description with the project name in it. There is never any guarantee that IProject.getName() and IProjectDescription.getName() will return the same thing though (we've never kept these in sync, for example if someone edits the .project and changes the name it has no effect).
Project name is handled in a special way when reading a project description from disk. This behavior was introduced with a fix for bug 15045. This way ProjectDescription kept in memory always returns the same as IProject.getName() (that is path last segment). See FileSystemResourceManager.read(IProject, boolean) for details. Considering the above is hard to change the code not to write actual project name along with other changes in the .project file. This is because the whole ProjectDescription object is dumped to an XML file. Therefore such a change would require hacking the code a bit to pass the information whether the write operation is triggered by project rename. And if such situation is not detected the name written would have to match the name already persisted on disk.
Created attachment 147089 [details] Patch_v01 Patch containing a rollback for bug 15045. I talk to Szymon and we agreed that name persisted in .project file should be treated as meta description of the project, not related to physical layout on disk. So, IProjectDescription.getName() should return the persisted value, not the last path segment like it does now. Consider a case when one checks out ProjectA from a VCS and renames it to ProjectA_HEAD. This is an operation that simply organizes project in workspace and should not trigger project's metadata change. Right now operation like this overrides metadata and causes an outgoing change on .project file. This is probably not what a user want. One thing that current UI lacks is an ability to change the name in .project. This could be solved by adding a check box in rename/copy dialogs or by adding such a property on project's properties page.
(In reply to comment #4) > One thing that current UI lacks is an ability to change the name in .project. > This could be solved by adding a check box in rename/copy dialogs or by adding > such a property on project's properties page. Bug 289337 tracks required API addition.
Changing target to 3.6 M3. The fix is attached and will be committed into HEAD right after M2 is out.
Released to HEAD. Thanks Pawel.
