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.

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?

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?)

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. :)
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.

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.

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

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.

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.