Description Fedronic valere 2008-01-28 09:56:14 EST

Created attachment 88015 [details]
The junit plugin test

Build ID: I20071213-1700

Steps To Reproduce:
The attached file contains a JunitTest that highlights the bug.
Just run the test 'testRefresh'

This is the scenario :

1) create a project with a jar file 'ext.jar' that contains a single class Ext.java with 'public static void foo()' method.

2) create a CompilationUnit with no associated java project, this is done thanks to the API WorkingCopyOwner#newWorkingCopy(String name, IClasspathEntry[] classpath, IProgressMonitor monitor)

3) The created CompilationUnit has only the main() method that make a call to the Ext.java#foo() method.

4) We can assert that there is no compilation problems (cu.reconcile())

5) Change the ext.jar contents with a new Ext.java class with a method bar() (instead of foo).

6) Update the java model (cu.getJavaModel().refreshExternalArchives()

7) Reconcile again

Expected : An error should detected (the foo() method doesn't exist)

Actual : No error, the jar model is out of synch.




More information:

Reproducible with 3.3.1.1 and 3.4M4

The problem seems to be that the DeltaProcessor#createExternalArchiveDelta() returns false in this case. It doesn't try to refresh the java projects because it considers that there are no java projects. But in fact there is an ExternalJavaProject.


I found a work around, but it use some discouraged access, and doesn't scale well :

packageFragmentRoot.close();
JavaModelManager.getJavaModelManager().getDeltaProcessor().projectCachesToReset.add(cu.getJavaProject());
JavaModelManager.getJavaModelManager().getDeltaProcessor().resetProjectCaches();