Summary: | JavaProject.resetCaches() needs to reset dependent projects | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jess Garms <jgarms> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | CC: | eclipse, thanson | ||||
Version: | 3.2 | ||||||
Target Milestone: | 3.3 M7 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Jess Garms
2006-05-31 16:44:36 EDT
Jerome - any chance of a fix to this in the 3.3 M6 timeframe? I'm not sure to understand your diagnosis. The project cache only caches classpath entries, package fragment roots, and package fragments. It doesn't cache types. So I don't see why resetting this cache would make FooGen visible in the hierarchy. Could you please provide more details on how to reproduce this issue ? A small plugin demonstrating the problem would be ideal. Yes, that is the problem: the package fragment roots are cached. In this case, a new package is created for FooGen, which does not always get picked up when compiling Project 2. I'm afraid a repro is difficult to produce as it currently would require a large subset of our Eclipse-based product. Let me know if the info above is sufficient to describe what's happening. Thanks! How is the package fragment created ? If you use IPackageFragmentRoot#createPackageFragement(...) this should reset the cache for you. Calling createPackageFragment() only seems to reset the cache in the *current* project, not in the dependent project. So in this case, Project 1 gets reset, but not Project 2. Thanks Jess. I now understand the problem. We should reset the caches of dependent projects as well in JavaModelOperation#run(IProgressMonitor) line 748. Created attachment 65007 [details]
Proposed fix and regression test
Fix and test released for 3.3M7 in HEAD. Verified for 3.3 M7 using build I20070427-0010 |