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.
[ BUILD # : 34d2eb3db637 ] [ JDK VERSION : 1.7.3 ] I will attach a sample project to reproduce it, but basically when using the new package view and trying to rename a package the refactoring is not working properly.
Created attachment 117252 [details] Sample project Select the new package view as Reduced Tree. 1. Open the sample project and expand the source packages until issue; 2. Rename the package issue to issue.packt and the class RefactoringIssue will present the package br.com.refactoring.br.com.refactoring.issue.packt. If the project is huge, the problem is really a mess.
Java Refactoring implementation of PackageRenameHandler.handleRename is not getting new name of the node but new full name of the package.
This is a poor API, since it makes assumptions about what the Node and its name represent. Better would be for PRH to take the original FileObject root, the original full package name, and the new desired package name (and make no explicit mention of a Node). Tried to write the current impl in TreeRootNode based on PackageRenameHandlerImpl.handleRename, which if isLeaf treats newName as a fully-qualified name. Either this block of code is just wrong, or it just works by accident when called from an empty PackageNode. Switching it to just call h.handleRename(this, name) does not work - from src/a/b/c/ renamed to "c.d", will create src/a/b/c.d/ rather than src/a/b/c/d/ as expected. refactoring.java owner needs to decide what PRH should mean, document it accordingly, and make sure java.project calls it that way.
Created attachment 117290 [details] Nonfunctional patch
The API was perfectly OK. PackageNode represented package. And it's name was a package name. Now it represents what? This is completely strange and it was never supported by refactoring: org + dont.know What represents "dont.know"? Java refactoring can do "rename NonRecursiveFolder" or "rename folder". "dont.know" is not folder and it is not nonrecursive folder.
Not a P3. Must be either fixed, or "Reduced Tree" feature rolled back.
(In reply to comment #5) > org > + dont.know > > What represents "dont.know"? Java refactoring can do "rename > NonRecursiveFolder" or "rename folder". > "dont.know" is not folder and it is not nonrecursive folder. Correct; it is a package component. So refactoring.java needs to be able to told to rename a package of one name to a package of another name. The exact appearance of the node hierarchy should be irrelevant from the perspective of the refactoring system. PackageRenameHandler is inadequate for this.
"package component" does not have any meaning in java language. Java Refactoring is able to rename package of one name to another name. org + dont.know + another.one + another.pkg If you rename "dont.know" it is not package rename. There is no concept of subpackages in java language. It is not able to rename "package component" because this construct is not defined anywhere. > The exact appearance of the node hierarchy should be irrelevant from the perspective of the refactoring system. Refactoring system is irrelevant from node hierarchy, but it must be integrated into existing UI.. OK. So to be exact. The bug is, that node "dont.know" claims, that it represents folder "know" which is not true. It represents "package component", which is not defined. From my point of view, we should rollback this Reduced Tree View, because it was not finished before FF.
(In reply to comment #8) > Java Refactoring is able to rename package of one name to another name. Sure, so this just needs to be exposed as a proper API at the model - not view - level, e.g. renamePackage(FileObject sourceRoot, String oldPackage, String newPackage, boolean includeSubpackages) which could supersede both PackageRenameHandler and FolderRenameHandler. (The latter by removing any special treatment from FolderNode.setName, i.e. Files view, and just having the tree-type views in java.project call the new API.) > org > + dont.know > + another.one > + another.pkg > > > If you rename "dont.know" it is not package rename. I think it is up to the UI - the view, i.e. Node - to decide what a rename of the node "dont.know" to "now.know" should mean. I would interpret it as renamePackage(root, "org.dont.know", "org.now.know", true) which I guess most users would also expect. > There is no concept of subpackages in java language. Right, but we show tree-type views already, and allow them to be renamed just by specifying that all packages with that prefix should be renamed. > node "dont.know" claims, that it represents folder "know" which is not true In fact it does represent that folder for most purposes, such as VCS, New File, etc. What is missing is a way to explicitly ask refactoring.java to perform a specific operation, rather than it inferring an operation from some incidental aspects of a Node such as getName(). > we should rollback this Reduced Tree View It would be crazy to undo one of the most commonly requested IDE features just because a relatively rarely used refactoring is unavailable. Package rename is anyway just a shortcut for multiselecting source files and doing a "move" rename, which is much more flexible as well. For now, I will just disable rename on these nodes since it is nonessential: core-main #ce3df9d99c0a
> > we should rollback this Reduced Tree View > It would be crazy to undo one of the most commonly requested IDE features just > because a relatively rarely used refactoring is unavailable. Package rename is > anyway just a shortcut for multiselecting source files and doing a "move" > rename, which is much more flexible as well. For now, I will just disable > rename on these nodes since it is nonessential: core-main #ce3df9d99c0a I sadly have to agree with Jesse... but I still hope it could be fixed for 7.2 FCS.
*** Bug 210110 has been marked as a duplicate of this bug. ***
> In fact it does represent that folder for most purposes, such as VCS, New File, etc. For most purposes? Definitely not. It does not represent this folder not only for package rename, but also delete does not work and move does not work as I would expect. This view is really half-baked.
I filed "Move" and "Delete" as separate issues (#210314 and #210315) Back to rename: Let's implement solution, which other IDEs have: Allow renaming only last part of "package component" corresponding to underlying folder and call FolderRenameHandler instead of PackageRenameHandler and it should work.
(In reply to comment #13) > Allow renaming only last part of "package component" corresponding to > underlying folder and call FolderRenameHandler instead of PackageRenameHandler > and it should work. Yes, I thought of that as a possibility pending a proper API. I think this would handle the majority of attempted renames. For other cases, IIRC throwing an IAE with a localized message allows the rename to be rejected with an informative message.
core-main #3ba2d8511c8b
v. Build 20120405-92366f9a458e
Integrated into 'main-golden', will be available in build *201204060400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3ba2d8511c8b User: Jesse Glick <jglick@netbeans.org> Log: #210107: [72cat] Rename package in reduced tree view Dividing rename handling into three cases: 1. If only the last component is changed, treat as a folder rename. 2. Else, if there are no subpackages, create a fake "list mode" node and pretend to rename that. 3. Otherwise, just show an error dialog and do nothing. #3 is unfortunate - the IDE could in principle handle it, given a suitable API ("RecursiveFolder"?) and refactoring impl; but this use case is not well handled by either list or tree modes anyway.