This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 183680

Summary: Need notifyRenamed distinct from notifyMoved
Product: projects Reporter: Jesse Glick <jglick>
Component: Generic InfrastructureAssignee: Jesse Glick <jglick>
Severity: normal CC: apireviews, tmysik, wex_viator
Priority: P3 Keywords: API, API_REVIEW_FAST
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 184501    
Bug Blocks: 165164, 183632    
Attachments: Proposed patch

Description Jesse Glick 2010-04-08 01:12:39 UTC
DefaultProjectOperationsImplementation.doRenameProject is too similar to doMoveProject, when all it should be doing is changing some metadata:

1. There is no good reason to close and reopen the project, when it should be the same Project object as before, i.e. assert project == nue. The MoveOperationImplementation's should be the same as well.

2. Calling MoveOperationImplementation methods is suspect. These are designed for an actual move, where project != nue. For example, J2SEProjectOperations loads and then restores various private metadata, some of which is unnecessary if you are only changing the <name>. Worse, AntProjectHelper.notifyDeleted is called, which could cause problems later when saving metadata.

#1 can be fixed in DPOI. #2 could be worked around in the project type, e.g. by doing nothing harmful in notifyMoving and having notifyMoved explicitly checking whether original == this. Or it might be cleaner to have a separate RenameOperationImplementation. (Not clear how to maintain compatibility in that case.)
Comment 1 Jesse Glick 2010-04-08 20:19:15 UTC
Created attachment 96926 [details]
Proposed patch

Includes new SPI (minus apichanges); usage; and a sample implementation in j2seproject.
Comment 2 Jesse Glick 2010-04-08 20:20:19 UTC
Please review this API change.
Comment 3 Jesse Glick 2010-04-08 22:53:39 UTC
*** Bug 180369 has been marked as a duplicate of this bug. ***
Comment 4 Tomas Mysik 2010-04-09 08:19:16 UTC
TM01 I would move handle.finish(); ( to the finally block.
Comment 5 Jesse Glick 2010-04-15 15:27:50 UTC
TM01 - not really necessary since the ProgressHandle is only actually displayed in a dialog, which is always closed when the operation finishes (whether successfully or not). I'm sure the code could be cleaned up in various ways but I don't think there is any visible bug in this area. Anyway the same comment would apply to any of the project operations, not just rename, so it is orthogonal to this issue.

Committed with updates also for ant.freeform and apisupport.project, and fixed main window title to immediately update when the selected project's name changes (previously you had to change the selection before this happened). core-main #83c32e15b1b6
Comment 6 Quality Engineering 2010-04-16 04:19:21 UTC
Integrated into 'main-golden', will be available in build *201004160201* on (upload may still be in progress)
User: Jesse Glick <>
Log: Issue #183680: offer a simplified way of renaming a project when it is not physically moved.