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
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
(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
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
>I don't think plugging into an existing refactoring is an issue - it is very
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
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
Look at the Refactoring API/SPI overview:
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
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
> 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)
Caused by: org.netbeans.editor.GuardedException: Attempt to remove from guarded
block at position 26,176.
... 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:
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. ***