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.
Open two Rails projects which contain a particular controller class, let's say AdminController. Invoke Open Type and confirm that you see two AdminControllers, two AdminControllerTests, etc. Now create a third project, a Ruby project. If you now open Open Type again, only one of the AdminControllers show up - and neither of the tests. This appears to be similar to issue 116769; -that- specific scenario is fixed, but there are other similar problems in this area. I took a brief look and it appears to be caused by code in RepositoryUpdater - code I don't understand very well. I wanted to file this issue since I've confirmed it on trunk sources. I will be integrating a fix for issue 119240 shortly, and I've spent a day investigating this new problem thinking it was a regression caused by my fix for 119240. I just confirmed that it's a problem in the trunk as well without my changes, so filing it now to investigate separately once I've integrated 119240.
Marking this bug evaluated since I know a lot about the bug, and I've left it unevaluated because I can't decide between "6.0" and "future" as the Target Milestone... I'm still on the fence what to do about it. I think it's highly desirable to fix it. The problem is that it's tricky. I've tried looking at it the last two nights I've been working on NetBeans stuff, but each time I realize that I'll need to look at it with a clear and rested head :) The impact of this bug is that project opening and closing seems to be overly aggressive and sometimes close indices for some open projects as well, meaning that Go To Type or code completion for local symbols will turn up empty. The workaround is simple - restart the IDE. Quite possibly, the scenario of having multiple projects open is probably much less common for Ruby/Rails development than it is for Java development. On the other hand, when it does happen, for example for scratch projects, it may be pretty confusing to the user. If I understand the schedule correctly, I have around 3 hours left until the freeze. I'm going to stay up and try to address it by then. However, I'm not confident that I'll be done, so I'm also applying for a waiver for this bug. I also plan to continue working on this bug tomorrow, and if I come up with a clean solution I will then apply for a high resistance integration and withdraw my waiver request.
I just integrated a workaround, hopefully in time for the 6.0 branching cutoff (my understanding is that it happens in 15 minutes). In fact, as far as I can tell the issue is fully fixed - I can't reproduce any problems around loadpath management right now. However, the fix is a bit messy, so I'm leaving the issue open as a P3 to track this down and revise this code. The root problem from all of this is that I took the Retouche RepositoryUpdater code and modified it to handle my own purposes. But the original class treats binaries as libraries and sources as non-libraries and treats the two very differently, which is not true for Ruby - after all the Ruby sources are also source directories not jars. Thus, I modified it in several ways that I now regret but I can't fix in a simple and risk free way. That will have to be 6.1; I need to make it understand .jar files again as well since that will be relevant for Java-completion in Ruby files (and other language clients of GSF).
Moving from ruby/GSF to editor/CSL. Step one: assign to myself ;-)
Step 2: trying to make the owner not myself but the owner of the subcomponent.
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX