Bug 209375

Would like to have this available also in java refactoring. I think this would help in solving #208495.

Created attachment 117655 [details]
Proposed API change.

Please review. Thanks.

Missing space in "method<code>resolveRewriteTarget</code>".


What would be the expected usage pattern in UseNbBundleMessages as an example? Currently this has something like:

ModifiersTree modifiers = ((MethodTree) enclosing).getModifiers();
ModifiersTree nueModifiers = generatorUtilities.appendToAnnotationValue(modifiers, ...);
wc.rewrite(modifiers, nueModifiers);

I guess this would be rewritten to:

ModifiersTree modifiers = (ModifiersTree) wc.resolveRewriteTarget(((MethodTree) enclosing).getModifiers());
ModifiersTree nueModifiers = generatorUtilities.appendToAnnotationValue(modifiers, ...);
wc.rewrite(modifiers, nueModifiers);

right?

By the way in core-main #dbb0f6059f57 I have tried to prepare for the new method by playing with a test for the corrected behavior in UseNbBundleMessages. Pending the API change, I expected assertOutput to fail after the second fix by showing just @Messages("k1=v1") rather than @Messages({"k1=v1", "k2=v2"}) as desired. But I also found two other failures:

1. assertVerbatimOutput shows Bundle.properties as containing "k2=v2\n" rather than "" as expected.

2. assertOutput shows org.openide.util.NbBundle.getMessage(Test.class, "k2") rather than k2() as expected.

Perhaps this is just a limitation in HintTest not being prepared for iteratively applied fixes? But then [JG01] HintTest ought to be fixed so that uses of resolveRewriteTarget can be tested like anything else in a hint.

The problem with 'org.openide.util.NbBundle.getMessage(Test.class, "k2")' is bug #201871. The problem with the bundle is caused by the fact that the resource content is not read and committed into the Document if available, which I have fixed in changeset jet-main#3c76cc153e62 (will become public soon). After fixing these two problems, the test passes, as the two "applyFix" invocations are independent (i.e. the test does not actually test the consecutive changes to one tree). So far, I do not have exact proposal how to extend the test harness to allow writing such tests (more precisely, the changes I have in mind so far - e.g. adding applyFixes() on HintOutput) might prove to be too limiting in the future). Might be overkill to defer the API addition until the test harness is enhanced.

The usage pattern is as you described.

(In reply to comment #6)
> I do not have exact proposal how to
> extend the test harness to allow writing such tests [...].
> Might be overkill to defer the API
> addition until the test harness is enhanced.

Agreed; just wanted to make sure this was at least under consideration. Ideally I would want to be able to write a test which fails until resolveRewriteTarget is used.

Integrated into 'main-golden', will be available in build *201204120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/dbb0f6059f57
User: Jesse Glick <jglick@netbeans.org>
Log: Commented-out test in preparation for #209375 (sequentially applied fixes).

Integrated:
http://hg.netbeans.org/jet-main/rev/4fe09b8ec828

Created #211087 for JG01.

Integrated into 'main-golden', will be available in build *201204130400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/3c76cc153e62
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #209375: non-Java resource changes must respect content of any Document opened for the given resource

Integrated into 'main-golden', will be available in build *201204140400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/3375b3dc27eb
User: Jesse Glick <jglick@netbeans.org>
Log: Taking advantage of #209375.