[GITHUB-9056] Using sharp(er) classpath when rename refactoring.
The Java refactoring is sometimes using class path (ClasspathInfo) that is, to me, extremely weird. In the specific case of https://github.com/apache/netbeans/issues/9056, the ClasspathInfo used to process GspIndenter does not in some cases contain the lexer module, while the groovy/groovy.gsp definitely lists it as a dependency.
The consequence of that is that there are compile-time errors in the file(s) with this broken class path. Sometimes, it may lead to "catastrophic" failures like: https://bugs.openjdk.org/browse/JDK-8373094
but even if it does not, wrong class path is likely to lead to weird effects. Like, in the test for the PR, testComplexRename1, inside main.Main, not only test(Side) will be renamed, but also test(String) will be renamed with the current state, as the classpath when analyzing main.main does not contain side.
The goal of this PR is to use class path that is more sensible for the rename refactoring.
^Add meaningful description above
Click to collapse/expand PR instructions
By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -
- are all your own work, and you have the right to contribute them.
- are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).
Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
If you're a first time contributor, see the Contributing guidelines for more information.
If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.
PR approval and merge checklist:
- [x] Was this PR correctly labeled, did the right tests run? When did they run?
- [x] Is this PR squashed?
- [x] Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
- [x] Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?
If this PR targets the delivery branch: don't merge. (full wiki article)
can confirm that this fixes the issue, I could rename the (heavily used) utility method with all projects open.