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: | Classpaths are not updated correctly | ||
---|---|---|---|
Product: | editor | Reporter: | Torbjorn Norbye <tor> |
Component: | CSL (API & infrastructure) | Assignee: | issues@editor <issues> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | pjiricka |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Torbjorn Norbye
2007-10-26 20:13:12 UTC
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 |