Community
Participate
Working Groups
build 3.3RC4 Add the following test in org.eclipse.jdt.core.tests.model.ResolveTests. public void testONLY_Bug() throws JavaModelException { this.workingCopies = new ICompilationUnit[2]; this.workingCopies[0] = getWorkingCopy( "/Resolve/src/test/p/Type.java", "package test.p;"+ "public class Type {\n" + "}\n"); this.workingCopies[1] = getWorkingCopy( "/Resolve/src2/test/p/Type.java", "package test.p;"+ "public class Type {\n" + "}\n"); IJavaProject javaProject = this.getJavaProject("Resolve"); IType foundType = javaProject.findType("test.p", "Type", this.wcOwner); assertElementEquals( "Unexpected elements", "Type [in [Working copy] Type.java [in test.p [in src2 [in Resolve]]]]", foundType); } When i run the test with the vm of jdk1.5.0_12 then 'Type [in [Working copy] Type.java [in test.p [in src2 [in Resolve]]]]' is returned. When i run the test with the vm of jdk1.5.0_08 then 'Type [in [Working copy] Type.java [in test.p [in src [in Resolve]]]]' is returned. The result should be always the same and the first type on the classpath would be better.
The problem is that the order of JavaModelManager.getWorkingCopies(....) result is not the same in both case.
See also bug 169970
Created attachment 76031 [details] Proposed fix and regression test The test given by David has been renamed to testWorkingCopyOrder1()
Fix and test released for 3.4M2 in HEAD.
*** Bug 194432 has been marked as a duplicate of this bug. ***
*** Bug 202152 has been marked as a duplicate of this bug. ***
Hi Jerome, We are using Eclipse 3.3 and we are developing some web service related plugins in Eclipse. This bug creates limitations in our functionality - for example the user is not able to generate twice same java bean skeleton out of WSDL in different projects. I would like to request this bug to be fixed in 3.3. I am from SAP LAbs Bulgaria and for us this is a real problem. thanks and regards, Georgi
Verified for 3.4 M2 using build I20070917-0010.
(In reply to comment #7) Sorry but the fix is not straight forward and since this is not a regression in 3.3 (the problem existed in 3.2 and before), we have no plan to backport it.