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.
Find Usages for Java classes is broken for me. I have tested 6.7.1, Dev 200907140201, and Dev 200907290201, always with a fresh $NB_HOME/var/cache. In a platform module suite I have a regular module A, which defines a public MyClass in a public package, and a module B, which depends on module A and directly uses MyClass from module A (e.g. invoking the standard constructor). Both module projects are open in the IDE. In all tested cases he IDE has been started with a fresh $NB_HOME/var/cache folder. Before invoking "Find Usages" I did wait until the initial scan was finished. In the "Find Usages" dialog I choose "All Open Projects", but the usages in module B are not listed in the results window! 1) There is no workaround known to me, 2) It is a regression, as it did work in earlier releases, 3) It corrupts data leaving the codebase uncompilable So I mark this as P1. Frank-Michael
I cannot reproduce it with the trivial project configuration. Can you please provide your project or sample project demonstrating this behavior? Are there any exceptions in the log?
I can find dozens of Caused: java.lang.NoClassDefFoundError: org/python/antlr/ModuleParser [catch] at org.netbeans.modules.python.editor.PythonParser.parse(PythonParser.java:116) at org.netbeans.modules.python.editor.PythonParser.sanitize(PythonParser.java:346) at org.netbeans.modules.python.editor.PythonParser.parse(PythonParser.java:93) at org.netbeans.modules.python.editor.PythonParser.parseFiles(PythonParser.java:315) at org.netbeans.napi.gsfret.source.Source.moveToPhase(Source.java:1064) at org.netbeans.napi.gsfret.source.CompilationController.toPhase(CompilationController.java:112) at org.netbeans.modules.gsf.GsfTaskProvider$Work$1.run(GsfTaskProvider.java:320) at org.netbeans.modules.gsf.GsfTaskProvider$Work$1.run(GsfTaskProvider.java:312) at org.netbeans.napi.gsfret.source.Source.runUserActionTask(Source.java:493) at org.netbeans.modules.gsf.GsfTaskProvider$Work.refreshFile(GsfTaskProvider.java:389) at org.netbeans.modules.gsf.GsfTaskProvider$Work.refreshFile(GsfTaskProvider.java:267) at org.netbeans.modules.gsf.GsfTaskProvider$Work.run(GsfTaskProvider.java:247) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030) for different *.py files (which I have reported with the exception reporter multiple times already). Note that I have Jython project support installed. Also I find messages like: WARNUNG [org.netbeans.modules.java.source.parsing.JavacParser]: ClassPath identity changed for C:\Users\moser\work\platform\modules\io\src\com\decodon\modules\io\FileMonitor.java, class path owner: C:\Users\moser\work\platform\modules\io (class org.netbeans.modules.apisupport.project.NbModuleProject) WARNUNG [org.netbeans.modules.java.source.usages.LuceneIndex]: Multiple index entries for binaryName: Pair[com.decodon.apps.delta2d.autoupdate.SoftwareUpdateDialog$2,null] WARNUNG [org.netbeans.modules.settings.convertors.XMLSettingsSupport]: Warning: unknown module code base: com.decodon.modules.delta2d.ui in C:\Users\moser\work\platform\suites\Delta2D\build\testuserdir\config\Windows2Local\Components\DualViewTopComponent.settings
I just have deactivated the Jython support. The exceptions are gone. But now I found WARNUNG [org.netbeans.modules.java.source.parsing.JavacParser]: ClassPath identity changed for C:\Users\moser\work\platform\modules\io\src\com\decodon\modules\io\FileMonitor.java, class path owner: C:\Users\moser\work\platform\modules\io (class org.netbeans.modules.apisupport.project.NbModuleProject) which is about the class I was searching usages for and WARNUNG [org.netbeans.modules.java.source.indexing.JavaIndex]: Ignoring root with no ClassPath: C:\Users\moser\work\platform\modules\delta2d-workflow\src\com\decodon\modules\delta2d\workflow which is about the module with the missing usages.
thanks for investigating
In com/decodon/modules/delta2d/workflow there is either the class which is missing from the usages result list but there are also some *.rb files. For those I have setup a Ruby project with the same package as src folder. That might have caused some conflicts: as a quick shot I also have deactivated the "Ruby and Rails" module, restarted the IDE (with a clean var/cache, as always) and, voilá, Find usages on FileMonitor gives a complete result now.
reproduced Steps to reproduce: 1) create module A with class TestClass 2) create module B depending on A with class public class Tester { public void akce() { TestClass tc = new TestClass(); tc.doIt(); } } 3) copy some .rb file under B's source root 4) create ruby project with existing sources, enter src folder from B as a source root (e.g. /home/user/NetbeansProjects/ModuleB/src) 5) call find usages on TestClass in module A Reassigning to ruby module after discussion with jpokorsky
Thanks for finding a reproducible use case. I don't think it is a common scenario to have two projects with the same sources, so this scenario is probably a P3. Furthermore, the project infrastructure is built on the assumption that every file belongs to <=1 project, so this is not really supported. The question is, why are both these projects needed? Why is the Ruby project needed at the same time as the NetBeans module project? Thanks.
I agree that for this scenario P3 is appropriate. However, the use case is valid: The platform module contains Java classes bridging some functionality provided in Ruby scripts. Both the Java classes and the scripts tightly belong together, in particular an extra module for only the scripts does not make sense. Now, to profit from basic refactoring capabilities in a Ruby project, I want to view the scripts from a Ruby project perspective. And I often switch between the Java and Ruby perspective in a session. So I definitely want to have both projects open at the same time.
Thanks for explaining. Erno Mononen, who owns the Ruby area, is now on vacation, so let's wait until he comes back so he can comment on this.
As Petr wrote before, this kind of setup (i.e. two projects with same sources) is unfortunately not supported at the moment. This should also not be necessary when we will have better Java/Ruby integration, including Ruby refactoring capabilities available in a Java project and vice versa. I'm afraid this may not be fixable for 6.8, but I'll take a better look at this still.