Community
Participate
Working Groups
We’re ran into a problem with generated types in the Model in Eclipse 3.1.2 with APT. Let me describe the situation: Project 1/ Foo.java, which creates (via APT): FooGen.java Project 2/ Bar.java, which extends FooGen.java Everything builds correctly from JDT’s perspective, but sometimes (about 1 in 3 on most machines), when APT is processing Bar.java in Project 2 after a full clean build has been started, it gets an inconsistent type hierarchy for it, and doesn’t see that Bar extends FooGen. The reason for this is that after both projects caches were reset during a clean, a separate plugin (non-generic Eclipse) was requesting an AST from project 2. This would cause project 2's caches to get loaded. After that both projects were built. Type generation in project 1 causes its caches to be reset, but not project 2. Then when project 2 was built, it used its cache and failed to find the new generated types in project 2. To work around this in 3.1.2, we added a call to JavaProject.resetCaches during our CompilationParticipant's build method, but obviously this is sub-optimal. Hopefully we can find a better solution for 3.2. I realize it may be too late for 3.2 proper, but since this problem requires a third-party plugin to actually occur, we could push this into 3.2.1.
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
