Summary: | Search broken | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | critical | ||||||
Priority: | P3 | CC: | martinae | ||||
Version: | 3.0 | ||||||
Target Milestone: | 3.0 M4 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Dirk Baeumer
2003-10-07 06:39:50 EDT
Created attachment 6346 [details]
The used JUnit version
Refactoring scenario was bogus (left over of classfiles in source folders), however we should not have been indexing them and failed later on. Fixed in v_374. Philippe, there isn't any bogus refactoring scenario involved here. I started from a fresh workspace and did a search which reported bogus results. Oops indeed no refactoring involved, but still the test case did contain extra classfiles which caused grief. Yes, there are some directories in the zip file which contain class files as well. The problem didn't show up when using v373b since I closed and reopen the project before doing the search. May be that makes a difference. Fix causes a NPE in DeltaProcessor. Reopening. Fixed NPE by caching the entry kind earlier in the RootInfo. Old indexes may contain invalid entry for .class files in source packages. Incremented IIndexConstants.SIGNATURE so as to recompute indexes. *** Bug 44349 has been marked as a duplicate of this bug. *** Verified |