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.
Refactoring is not well integrated with form module. Consider for example rename of some field generated by form editor. The occurences outside the guarded blocks can be renamed using Refactoring > Rename action on the node that represents the field. Unfortunately the .form file is not modified and therefore the occurences in the guarded blocks are not renamed. The occurences inside the guarded blocks can be renamed for example by Rename action on the corresponding node in the Inspector, but this action doesn't rename occurences outside guarded blocks. By now the user must perform both steps (in this order) to achieve a complete rename.
*** Issue 53392 has been marked as a duplicate of this issue. ***
Closing a defect by marking it as a duplicate of a task is a great way to get the bug count down. Is there any commitment to DO this task? This has been reported as a defect by users. See the defect that has been closed as a duplicate of this?
This task definitely deserves a higher priority. IMO this is a must have for 4.2. P3->P1
Let's target this for 4.2 - it would be really desirable to have it done. Hopefully somebody from refactoring team will help us ;)
*** Issue 44267 has been marked as a duplicate of this issue. ***
*** Issue 59140 has been marked as a duplicate of this issue. ***
*** Issue 59628 has been marked as a duplicate of this issue. ***
There has been a fair number of issues raised about this. This really needs attention.
This bug has 8 votes. It deserves evaluation.
*** Issue 67777 has been marked as a duplicate of this issue. ***
As it has been already written - it would be really desirable to have it done. Unfortunately it will not be done for NB 5.0.
*** Issue 70465 has been marked as a duplicate of this issue. ***
*** Issue 70893 has been marked as a duplicate of this issue. ***
If this does not get completed soon I will fly to Prague and stand in the NetBeans office, in my underwear, singing, until it is fixed; consider this fair warning. (As a hacky but workable fixed, why can't the two operations just be tied together? Refactor Outside invokes a rename on the form after it's done and rename inside invokes a refactor after it's done?)
*** Issue 71696 has been marked as a duplicate of this issue. ***
*** Issue 72587 has been marked as a duplicate of this issue. ***
*** Issue 80767 has been marked as a duplicate of this issue. ***
*** Issue 75187 has been marked as a duplicate of this issue. ***
*** Issue 78450 has been marked as a duplicate of this issue. ***
*** Issue 71570 has been marked as a duplicate of this issue. ***
*** Issue 83722 has been marked as a duplicate of this issue. ***
Do any refactoring APIs have the ability to attach refactoring listeners and have event firing mechanisms? If not that would be the best solution to address these situations not only with form, but with other modules which may be or want to be using refactoring.
Guys, a form is just a XML file. Sourced on this xml file, the .java file is created (or merged?). So what is difficulty for write a refactoring module that is able to deal with forms? Indeed, JackPot need to deal with this situation too. What's planned for?
I don't think plugging into an existing refactoring is an issue - it is very easy. :)
>I don't think plugging into an existing refactoring is an issue - it is very >easy. :) Apparently I'm missing something, because the issue seems to be related to just this, and then there is a comment from Tomas about getting help from the refactoring team. In the current documentation at platform.netbeans.org there is the RefactoringActionsFactory (which I assume should be firing actions for this issue): http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-refactoring/org/netbeans/modules/refactoring/api/ui/RefactoringActionsFactory.html I then see in refactorings there is an SPI for refactorings, but I do not see any services in the form sources. I would think form could implement org.netbeans.modules.refactoring.spi.SimpleRefactoringElementImpl SPI, but it doesn't, so I'm trying to figure out why not, and if I am missing other things to the puzzle here as to how to tie into refactoring. The poor documentation (at least the documentation I can find) on the refactoring SPI and API doesn't help however.
Look at the Refactoring API/SPI overview: http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-refactoring/overview-summary.html In the use-case section for SPI there is a short overview of how to plug in a functionality for a refactoring. In case of Form editor, it would probably be best to implement GuardedBlockHandler/-Factory from the spi package (better description of those classes would be desirable). As I said, plugging something in is pretty simple. But the implementation of that something (i.e. replacing the right pieces of the XML file representing the Form metadata) may be tricky - that's the core of what the Form team needs to implement. I guess the reason why you don't see any implementation of refactoring SPI in Form is it is not integrated with the refactoring right now - that's what this issue is all about, right?
Well, the issue says: "Refactoring is not well integrated with form module" , but I don't think it is integrated at all, and was partially contributing to my confusion. It has only refactoring support built in partially to the form module itself and only the areas it specifically defines them, but there is no integration at all with the rest of the system. That is what I was wanting to make sure the case was. I'm pretty sure it isn't integrated at all currently. Unless there is some other means (other than refactoring SPI) in which the platform can send events or actions for refactoring and the form module is listening to these actions. That is partially why I posted before whether there was an API in refactoring modules could register. Anyways, I'm assuming the only way to hook into refactoring is to use the SPI and since form doesn't define any services then it does not integrate at "all" currently with refactoring. On the subject of Jackpot and this issue or ones like it in general. Is there going to be another API for refactoring, or does Jackpot currently use the refactoring APIs and this will continue to be used? Is Jackpot going to define another API which could be better utilized and will become part of the platform? I assume the Java Model is going to be changed to use the new compiler JSR per Tim's interview at artima. Anything anyone should be looking at here for future use and relation to this issue?
Just read over JSR 199 APIs. I guess I don't see how it would affect refactoring except maybe behind the scenes leaving the interface to the refactoring API the same, so unless Jackpot adds any new refactoring APIs then I guess I answered my own question.
Tomas or anyone else from the form project. Is anyone working on this issue currently, or would it be marked as such (started or assigned to a name) were it started? I might start add a couple of things to code from the trunk and see about a patch or something. Maybe just the basic needs. Dealing with class and variable renaming.
> Is anyone working on this issue currently, or would it be marked as such >(started or assigned to a name) were it started? No, nobody is working on this issue by now. The main reason are resource problems and big deal of uncertainty about changes in java infrastructure. As for the first reason - we understand to the importance of this issue, but it is a big deal of work and we simply don't have enough resources to implement it, by now. As for the second reason - it is not clear how the refactoring APIs will be affected by the new java infrastructure. Sure, it may (and hopefully will) happen that the APIs will remain the same, but the APIs are not all. For example, the current java infrastructure has many rules how this or that should be accomplished and these rules are not well (or at all, if you prefer ;-)) documented. I am sure that these rules will not stay the same :-(. > I might start add a couple of things to code from the trunk and see > about a patch or something. Maybe just the basic needs. Dealing > with class and variable renaming. It would be great, definitely.
*** Issue 78935 has been marked as a duplicate of this issue. ***
*** Issue 88604 has been marked as a duplicate of this issue. ***
Just for note: I'm waiting on the new 6.0 Java infrastructure and it to be stabilized before attempting to work on this. If someone else is working on this or planning on it let me know and I will not bother. I'll mark it as started if and when I get to it just waiting on 6.0, and I do not plan on back porting, but once I get it into 6.0 it might not be such a hard thing depending on the API changes...we'll just have to see.
*** Issue 89001 has been marked as a duplicate of this issue. ***
*** Issue 91639 has been marked as a duplicate of this issue. ***
36 votes for this issue, 20 duplicates. P3 is not appropriate IMO.
I just came across another problem: I added an interface to my Matisse-developed JPanel and took NB up on its offer to implement all the interface's methods. But that causes an exception in the latest (11012007) build :-( java.io.IOException at org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:90) at org.netbeans.modules.java.hints.ImplementAllAbstractMethodsCreator$FixImpl.implement(ImplementAllAbstractMethodsCreator.java:165) at org.netbeans.modules.editor.hints.HintsUI$1.run(HintsUI.java:498) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963) Caused by: org.netbeans.editor.GuardedException: Attempt to remove from guarded block at position 26,176. at org.netbeans.editor.GuardedDocument.preRemoveCheck(GuardedDocument.java:188) at org.netbeans.editor.BaseDocument.remove(BaseDocument.java:757) at org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:85) ... 4 more
*** Issue 94594 has been marked as a duplicate of this issue. ***
we should try to fix this for 6.0
*** Issue 97744 has been marked as a duplicate of this issue. ***
*** Issue 98336 has been marked as a duplicate of this issue. ***
*** Issue 76326 has been marked as a duplicate of this issue. ***
this is new functionality, changing issue type to be clear on that. it's planned for M10.
I *SO* don't agree that this is a new feature. Since when is correct functionality a new feature?? Unless it's just a way to close bugs ...
Glad to see that you are taking this issue on.
santafen, who said it is closed. It has a priority of P1 and will be worked on soon. The goal is to have it in NB 6.0.
It is now a P1 *feature* not a P1 *bug*. As I said, fixing something to work correctly is usually not considered a 'feature' but rather a bug fix. Semantics, I grant you, but rather important. Having rename/refactor work correctly is, I guess, in some odd way, a feature. I also don't believe that this bug addresses the issue I raised in <http://www.netbeans.org/issues/ show_bug.cgi?id=76326> in that this issue only addresses form elements, not Bundle resource elements, but I'll wait to see if they are addressed together.
*** Issue 103520 has been marked as a duplicate of this issue. ***
*** Issue 103891 has been marked as a duplicate of this issue. ***
*** Issue 104088 has been marked as a duplicate of this issue. ***
*** Issue 104382 has been marked as a duplicate of this issue. ***
So hopefully some good news: We've implemented the main refactoring scenarios in GUI builder. Should appear in trunk builds on Monday. Obviously we were not able to do everything at once, but the most typical use cases should be covered (should be a huge difference from _nothing_ as it was so far). These are the implemented scenarios: - Renaming a component variable - Renaming/moving a component class (being used in GUI forms) - Renaming/moving the form class itself - Renaming a package The changes also include updating the internationalization keys, moving/renaming properties files, resources for the new Swing App Framework (JSR-296), and all changes fully support undo. For more details see: http://wiki.netbeans.org/wiki/view/GUIBuilderRefactoring For the rest of the unsupported scenarios I've created issue 106831. Subscribe to this issue if you are interested in further progress in the future. Also if you find some of the duplicates here (48288) still not implemented, please reassign it under the new issue. Marking as fixed.
*** Issue 108063 has been marked as a duplicate of this issue. ***
*** Issue 56549 has been marked as a duplicate of this issue. ***
*** Issue 73111 has been marked as a duplicate of this issue. ***