Created attachment 117393 [details]
API class

    <changes>
        <change id="RefactoringSupport">
            <api name="JavaHintsSPI"/>
            <summary>Added support for using jackpot patterns from other modules (e.g. refactoring).</summary>
            <version major="1" minor="1"/>
            <date day="28" month="3" year="2012"/>
            <author login="jbecicka"/>
            <compatibility addition="yes"/>
            <description>
                <p>
                    Added support for using jackpot patterns from other modules (e.g. refactoring).
                </p>    
            </description>
            <class package="org.netbeans.spi.java.hints.support" name="RefactoringSupport"/>
            <issue number="210262"/>
        </change>
    </changes>

Thanks for the proposal. A few comments:
JL01: the "support" package may not be very appropriate for this class. Generally when a class from the support package is copied into a different module, it should still compile, which is not the case of this class
JL02: after thinking about a little bit more, it might be meaningful to use a builder-like pattern, used e.g. in the org.netbeans.api.java.source.matching.Matcher. I will attach a sketch. This might be more future-proof.

Created attachment 117397 [details]
A sketch of a builder-like possibility to implement the RefactoringSupport.

Created attachment 117446 [details]
TransformationSupport

Version 2.0

(In reply to comment #5)
> Created attachment 117446 [details]
> TransformationSupport
> 
> Version 2.0

API looks good to me.

http://hg.netbeans.org/jet-main/rev/39274bf203c9

I think there is something wrong with mail delivery since I never saw any notifications about this issue.


(In reply to comment #3)
> when a class from the support package is copied into a different
> module, it should still compile

More precisely, it should be possible to copy the class including its transitive static dependencies (and resources) into another module with the same dependency list, and the result should not only compile - i.e. not be using any restricted packages - but any code _using_ the original class and updated to use the new class should also compile, and (in the case of non-type-safe APIs like Map<String,?>) behave the same (i.e. no other code is casting to the original type).

I think the distinction is irrelevant in this case since no other code in the API refers to TS, but still as JL01 said it has privileged access to private packages so it is not a support class and should preferably not be named that way.


[JG01] I do not think {@link https://bitbucket.org/...} is valid Javadoc syntax, but even if it were, such external links would be flagged as test failures by nbms-and-javadoc. (nbbuild/javadoctools/disallowed-links.xml)

as for support. The change is already committed. So should I do incompatible change and rename/move it somewhere?

JG01: fixed

I guess it is not important enough to change now. jlahoda any opinion on that?

Integrated into 'main-golden', will be available in build *201204021038* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/39274bf203c9
User: Jan Becicka <jbecicka@netbeans.org>
Log: Issue #210262 - API Addition TransformationSupport class