This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | New API class to specify a limited scope for WhereUsedQuery | ||
|---|---|---|---|
| Product: | editor | Reporter: | Ralph Ruijs <ralphbenjamin> |
| Component: | Refactoring | Assignee: | Ralph Ruijs <ralphbenjamin> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jbecicka, jglick, ppisl |
| Priority: | P3 | Keywords: | API, API_REVIEW_FAST |
| Version: | 7.1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 200437, 197194, 200439 | ||
| Attachments: |
Proposed patch
Updated patch |
||
|
Description
Ralph Ruijs
2011-06-30 11:55:00 UTC
Created attachment 109164 [details]
Proposed patch
Patch is OK for me. CCing Jesse and Petr. This Scope will be used in Find Usages to limit scope (current file, current package, selected folders etc..) and AFAIK apisupport.refactoring and j2ee.refactoring has some find usages plugins which should be updated to respect Scopes. TZ01: I would prefer to have a addFolder (addFile) methods. Returning a Set into which client adds the files may be dangerous. A client may remove an already added file or hold a reference to the set and do a mutation of it in other thread causing ConcurrentModificationException. I have to agree with Tomas TZ01. The javadoc for the method getFiles() and it's name somehow sounds strange to me. Also using set looks suspicious. Created attachment 109288 [details]
Updated patch
TZ01: I changed the scope to be unmodifiable. Added a create method to build the scope.
[JG01] Perhaps it is off topic, but for bug #191334 I need the ability to introduce a new scope (Maven repository). This API change does not look like it would help at all. Seems good to me. Re [JG01] Yes, it is off topic. This API change is about local scopes. It will not help with maven issue, on other hand it also does not make things worse. I will integrate it tomorrow. Changeset: 297c45376765 Author: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org> Date: 2011-07-13 10:22 Message: Issue #199779 - New API class to specify a limited scope for WhereUsedQuery When there is a working UI that defines Scope's, please file a dependent issue for apisupport.refactoring to pay attention to it. (I do not promise to work on it promptly since this module is not a high priority, especially with newer APIs using annotations that require no special IDE support.) I could also modify the new maven.refactoring to suppress local repo search when there is a Scope clearly indicating an explicit user restriction to the scope. Just from the API alone I cannot judge how this would be possible; will the Scope object be entirely missing from the context when Find Usages is invoked with no special gesture? If it is present and prepopulated with source roots from all open projects (or whatever), then maven.refactoring cannot easily tell whether the user meant to specifically limit the scope or not. Obviously it would be best to have a separate checkbox "Check Maven Repository" in the Find Usages dialog, but no API supports this that I know of. Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/297c45376765 User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org> Log: Issue #199779 - New API class to specify a limited scope for WhereUsedQuery Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/27f9b03428f4 User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org> Log: After fix of bug #200230, some find usages implementations broke. ClasspathInfo needs to be in context until #199779 is used in all modules. |