Bugs item #3540379, was opened at 2012-07-05 00:00 Message generated for change (Comment added) made by flofreud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=843359&aid=3540379&group_id=167540
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Synchronisation / Invitation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Starroske (starroli) Assigned to: Nobody/Anonymous (nobody) Summary: Rework the method projectNameIsUnique(..) Initial Comment: The method EnterPageNameUtils.projectNameIsUnique(..) is used at different places with different intentions: 1) test if the given name is included in a list of reserved project names 2) test if a project already exists in the current workspace 3) test if file with the given name exists in the current directory of the workspace Intention 2) is not implemented correctly: The Eclipse API should be used to determine, if a project exists already in the workspace. Projects which are not physically located in the workspace are not included in the check. Intention 3) is implemented to uses Java.IO.File to check this. Maybe ther is a way to do this using the eclipse API ---------------------------------------------------------------------- Comment By: flofreud (flofreud) Date: 2012-11-11 14:40 Message: 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. ---------------------------------------------------------------------- Comment By: Franz Zieris (franzzieris) Date: 2012-09-04 08:14 Message: @Sebastian: Are you still working on this, or do you want to set this tracker item free? ---------------------------------------------------------------------- Comment By: Stefan Rossbach (kargor) Date: 2012-07-05 17:03 Message: 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=843359&aid=3540379&group_id=167540 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Dpp-robot mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dpp-robot
