Bug 183680 - Need notifyRenamed distinct from notifyMoved
Need notifyRenamed distinct from notifyMoved
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
6.x
All All
: P3 (vote)
: 6.x
Assigned To: Jesse Glick
issues@projects
: API, API_REVIEW_FAST
: 180369 (view as bug list)
Depends on: 184501
Blocks: 165164 183632
  Show dependency treegraph
 
Reported: 2010-04-08 01:12 UTC by Jesse Glick
Modified: 2010-08-18 18:55 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Proposed patch (14.41 KB, patch)
2010-04-08 20:19 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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(); (DefaultProjectOperationsImplementation.java) 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 http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/83c32e15b1b6
User: Jesse Glick <jglick@netbeans.org>
Log: Issue #183680: offer a simplified way of renaming a project when it is not physically moved.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo