Rework the method projectNameIsUnique(..)

Analyse issue 3. I think this requirement is not needed,

so the code is

Set<IProject> currentProjects = new HashSet<IProject>

currentProjects.addAll(Arrays.asList(ResourcePlugin.getWorkspace().getRoot().getProjects())

for (String reservedProject : reservedProjects)
currentProjects.add(ResourcePlugin.getWorkspace().getRoot().getProject(reseverdProject)

return ! currentProjects.contains(newProject)

@Sebastian: Are you still working on this, or do you want to set this tracker item free?

We, Robert Fehrmann and Florian Freudenberg, want to fix this issue in context of the course "Softwareprozesse".

We did an inspection of the related code of EnterProjectNamePageUtils.projectNameIsUnique(...) and come to conclusion, that some parts of the code need to be corrected.

1. We want to check for the projects, which are known by eclipse, like suggested in the issue report but will also retain the check on file basis.
2. We will insert a flag for this last check into the method signature.
3. We will rework some of the callees of this method so that it is easier to understand.

to 1.
We found one failure caused by this fault, so that the check for projects known by eclipse is definitely needed. If a session is opened and the related local project is inside the workspace-dir the wizard will preselect the equal named project when the "Use existing project"-option is clicked. If the project is located outside this does not works, because the wizard dont recognize it. There would be more such problems, if the method would be used correctly (see to 3.).

to 1 + 2.
Following the intention of the method we would only need to check for project existence with the Eclipse API, but this would introduce new faults. The IncomingProjectNegotiationProcess assumes that if the project name is not known by Eclipse, it can create a new project in the workspace-dir. But this is a show stopper because the whole process ends with an exception, if this dir already exists (like after the project is deleted without file system deletion). Following that we will have to still check for dir existence in the context of new project creation because of the simplification assumption of the IncomingProjectNegotiationProcess.
But if we would always check for dir existence, this would also be wrong in context of the "Use existing project"-proposals, because he will propose a non existing project.

This could also be solved by extraction the functionality and check it where needed explicitly, but we think the readability of the code would suffer.

to 3.
The current implementation has only these little usability issues, because the method is not used correctly. At one callee all projectnames known by eclipse are provided on the reservedNames list, which would be used for names reserved by the wizard. The JavaDoc for the method does not explain the propose of the reservedNames list and therefore its hard to understand it. So we want to rework the callees and provide better JavaDoc for that method.

The changes would only effect the EnterProjectNamePage and the EnterProjectNamePageUtils. We checked all dependencies of our proposed changes like in the IncomingProjectNegotiationProcess.

Probably we should also change the message text of EnterProjectNamePage_error_set_projectname2 that mentions a "Scan for matching projects"-function which is not provided.

If there is no objections against our proposal we would provide a patch to review next week.

I think my patch

http://saros-build.imp.fu-berlin.de/gerrit/#/c/333/

already resolves anything that is issued here. If there is something missing feel
free to provide more informations.

c6259b39f0cf0854e8094027aa8463d9d685cd99

c6259b39f0cf0854e8094027aa8463d9d685cd99