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.
Created attachment 152577 [details] Project structure to demonstrate Find Usages issue The Find Usages feature does not take in account classes generated by APT across projects. The situation is that I have several ANT-based projects. The main project depends on three projects. The first one is just an API project for the second one which implements an APT processor. The class generated by the processor is using a class from the third project. When building the whole structure, everything is OK. The issue is when going to a common utility class and hitting Find Usages feature. Expected result: - The generated classes are being listed - The Test classes are also mentioned as well Actual result: - Only Test classes are listed Please find attached a test project structure. Product Version: NetBeans IDE 8.0.2 (Build 201411181905) Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 1 Java: 1.8.0_31; Java HotSpot(TM) 64-Bit Server VM 25.31-b07 Runtime: Java(TM) SE Runtime Environment 1.8.0_31-b13 System: Mac OS X version 10.10.2 running on x86_64; UTF-8; en_US (nb) User directory: /Users/petr/Library/Application Support/NetBeans/8.0 Cache directory: /Users/petr/Library/Caches/NetBeans/8.0
APT generated class is processed by SourceAnalyzer, however, ClassIndex.getResources(...) called from the JavaWhereUsedQueryPlugin does not return its corresponding FileObject
There are 2 problems. The one is a NB bug and the second is a project set up. 1) The NB bug is that it cannot resolve the apt generated file. 2) The project set up - the APT is a project, doing clean on FindUsages does also clean on all dependencies (APT project) the processor is deleted and all sources are rescanned without the processor (there is an error badge missing HelloClass). So it's better to add the processor as a jar not as project. However IDE should rebuild just the projects on COMPILE CP not on AP CP.
The java.source part (ClassIndex.getResources) is fixed, see issue #251952.
But the problem is in java.refactoring which ignores the apt output. Can be fixed in JavaWhereUsedQueryPlugin by an attached patch however still does not work due to JavaRefactoringPlugin.groupBySourceRoot() which removes the apt output as well.
Created attachment 153275 [details] Patch
(In reply to Tomas Zezula from comment #4) > But the problem is in java.refactoring which ignores the apt output. > Can be fixed in JavaWhereUsedQueryPlugin by an attached patch however still > does not work due to JavaRefactoringPlugin.groupBySourceRoot() which removes > the apt output as well. Refactoring filters on PathKind.SOURCE as source files are only what is supported right now. Can't the generated sources, by APT but also others, be added to this or a new PathKind.GENERATED ? Looks strange to have to query a specific implementation about their source roots.
Hi Ralph. The situation is even more complicated, this is the reason I've increased it to P2, as it may take longer time to decide how to solve it. All the generated source roots except of the processor generated roots are a part of the source path. AddingPathKind.GENERATED would duplicate the them. Also there is no way how to detect them (except of the processor generated roots which can be found by AnnotationProcessingQuery). The Processor generated roots are "invisible" for the java compiler. Otherwise they will cause Duplicate Class Errors as the Processors may run in the editor. I think there are two possibilities: 1st) JavaRefactoringPlugin can detect them by AnnotationProcessingQuery. 2nd) Add also the processor generated roots to source path. The second one will require several changes in the java.source.base. The j.s.b already filters processor generated roots from the source path to get internal source path and java custom indexer ignores them, which is OK. However SourcePathCheck and ClassPathProviders will need to be changed. So the 1) may be easier. If not we can try 2).
(In reply to Tomas Zezula from comment #7) > ... > I think there are two possibilities: > > 1st) JavaRefactoringPlugin can detect them by AnnotationProcessingQuery. JavaWhereUsedQueryPlugin can detect the AProots, but as JavaRefactoringPlugin only gets FileObjects, ClassPath.getClassPath currently is not able to get a cp for files from APT. > 2nd) Add also the processor generated roots to source path. I think this would need to be implemented.
Not a P2.