Summary: | SetClasspathOperation no longer adds project for refresh | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jason Peterson <jasonpet> | ||||||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | critical | ||||||||||
Priority: | P3 | CC: | balakuma, cbridgha, eric_jodet, philippe_mulet | ||||||||
Version: | 3.4 | Flags: | philippe_mulet:
pmc_approved+
|
||||||||
Target Milestone: | 3.3.2 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Jason Peterson
2007-12-12 11:07:03 EST
Are you saying that you don't get a delta for external jars when modifying the raw classpath? Is the classpath set by SetClasspathOperation different from the previous classpath? No, I do get a delta. The classpath is changed and there is a delta. DeltaProcessor is invoked, but the following code is never reached now in JDT 3.3: if (elementsToRefresh != null) { createExternalArchiveDelta(elementsToRefresh,null); } The problem is with elementsToRefresh. This is always null now. The following method in DeltaProcessState is never called now from the SetClasspathOperation public synchronized void addForRefresh(IJavaElement externalElement) { if (this.externalElementsToRefresh == null) { this.externalElementsToRefresh = new HashSet(); } this.externalElementsToRefresh.add(externalElement); } In JDT 3.2 this method was in DeltaProcessor instead of DeltaProcessorState. That is not the issue though. The issue is that in 3.2 this method was invoked by the following line of code in SetClasspathOperation: JavaModelManager.getJavaModelManager().getDeltaProcessor().addForRefresh(project); In JDT 3.3 this code is never invoked. I added the following code to invoke it just as it was in 3.2 and it fixed the problem: JavaModelManager.getJavaModelManager().getJavaModel().refreshExternalArchives(new IJavaElement[] {project}, null); NOTE: refreshExternalArchives is the code in JDT 3.3 that calls the addForRefresh(IJavaElement externalElement) Created attachment 85109 [details]
Proposed fix and regression test
Note the change is not in SetClasspathOperation has this needs to work also if the .classpath file is changed manually.
I will release the patch after more testing.
adding to the cc list to get notified when the patch is released. Thanks for the quick response. I tried out the patch to test the refresh issue. The refresh is now working as it did in 3.2. However, I am still getting class not found exceptions due to an invalid classpath. I was on the right path with the refresh in the SetClasspathOperation, but the root of my problem is actually the fact that the following line is missing in the SetClasspathOperation.executeOperation(): project.updatePackageFragmentRoots(); NOTE: This line was right above the refresh for the 3.2 code. The issue is that our code is doing a setClasspath and soon after that validation is being done on the type hierarchy for some classes in the project. This is looked up by doing a IJavaProject.findType(String packageName, String typeQualifiedName) This in turn gets the project's cache and passes the arg cache.allPkgFragmentRootsCache (first of 5 args) to NameLookup. However, without the project.updatePackageFragmentRoots() being called in SetClasspathOperation, cache.allPkgFragmentRootsCachehas not been updated yet and is missing all of my WAS Container jars. Created attachment 85276 [details]
Additional fix and new regression test
Created attachment 85292 [details]
Fix and regression tests for 3.3.2
Note that the external jar delta problem is not present in 3.3.x. So only the project's cache problem is being backported. However the 2 tests are being backported.
We should backport the fix from comment 7 to 3.3.2 since: - this is a regression comparing to 3.2 - clients that update their model by listening to Java deltas cannot work around the problem - the fix is a one line change Asking for PMC approval to backport to 3.3.2. +1 for 3.3.2 Fix and tests from comment 7 released for 3.3.2 Verified in the code for 3.3.2 using M20080123-0800 build |