Community
Participate
Working Groups
3.2.2.v20070208 So far, I have been unable to reproduce the following scenario, however, a customer can and I have see a video of it occurring. This seems like it may be related to bug 262769. If it is not related, then it is probably similar. It is very important that we resolve this problem for our customer as quickly as possible, and I will continue with my attempts to reproduce and will log any updates here. Of course the customer's workspace is far more complex, but the key pieces are as follows: There are two projects, A and B. B has a project classpath dependency on A. B also has a jar called util.jar which B has a classpath dependency on. Now, the key part: A has a dependency on util.jar in B. On the surface this sounds strange and almost cyclical, but it is not, and during the runtime scenario it makes perfect sense. :) Now, suppose the above two projects, A and B are imported into the workspace as existing projects from the file system one at a time. Furthermore, let auto-build be off. First bring in A. Next bring in B. Now do a build. The problem the customer is seeing is A fails to add B's util.jar to its workspace classpath. The entry is indeed in A's .classpath file, but JDT doesn't resolve it. Rebuilding and cleaning does not fix this. Deleting and reimporting A into the workspace does fix this. I'm attaching a zip of this scenario and a screenshot.
Created attachment 85735 [details] zip of example projects A and B
Created attachment 85736 [details] screenshot
Adding more info to this scenario..... and should replace project B as a "simple" non-java project. The issue is project A has a reference to a jar within this simple project that may not be in the workspace. When Project B is imported - project A's classpath is not refreshed - so the stale unresolced error marker still exists - even with a project clean. Once project A is closed then reopened - the problem goes away.
A couple of findings: In eclipse 3.3.1 situation is slightly different - when auto build is disabled it is enough to import project B and request build. When auto build is enabled, it is necessary to clean project A, and then everything works fine. Therefore I believe that the one should look for hints in the build job. What have changed between R3_2_2 and R3_3_1?
another thing we found with Chris: if during importing B you check "Copy projects to workspace" then A will be built with next Clean. (tested on 3.2.2 M20070212-1330)
JavaBuilder.isClasspathBroken makes impossible to build any project that contains IJavaModelMarker.BUILDPATH_PROBLEM_MARKER. Action Plan: Looking where that markers are set.
Created attachment 86043 [details] Solution idea This patch illustrates basic solution idea. I am forcing the JavaBuilder to reload classpath before build if classpath is broken. Patch is prepared on eclipse 3.2.2. I will port it to head release later. Action plan: Try to improve patch. Possible ways: a. integrate forced classpath reload with refresh action (will work if refresh is called after import). b. add specialized condition to force refresh if and only if the current project is depended on jar that lies in project that had not been built yet. Later: port patch to the head stream.
Unluckily, this patch works only for disabled auto build.
(In reply to comment #5) > another thing we found with Chris: if during importing B you check "Copy > projects to workspace" then A will be built with next Clean. > (tested on 3.2.2 M20070212-1330) continuing this, it seems the difference comes from the fact, that in ClasspathEntry#validateClasspathEntry(....) call to JavaModel.getTarget() - to retrieve /B/lib/util.jar returns null. In project /B only it's root (/B) exists at this time, it's not in sync with filesystem (isSynchronized(1) returns false)) and has no members. Whereas if "Copy projects to workspace" is checked, resources exist already.
Patch seemed to work because of race condition. Replacing the code with Thread.wait had similar effect. I am trying to follow another path. I have noticed that classpath entries are validated while refreshing workspace. We can track this from DeltaProcessor.resourceChanged to JavaModel.getTarget. Now if getTarget will return null, ClasspathEntry.validateClassPathEntry(IJavaProject, IClasspathEntry, boolean, boolean) will create marker (none of its condition will be fulfilled). One thing that makes me worried is fact, that when I look into the JavaModel.getTarget I see called WorkspaceRoot.findMember(/B/lib/util.jar) that is not able to locate the file. Null is then returned, marked set, and the project will never be compiled again. So the problem seems now be more related to resources. Action Plan: 1. check bugs against resources.
Sorry Jacek, I missed your comment. I am pretty tired now ;-). So how can we deffer classpath verification?
Just one more guess: I think this behavior is caused by following race condition: One job is synchronizing workspace (POST_CHANGE change), and another is trying to set up classpaths (PRE_BUILD). It seems to me that PRE_BUILD may happen before POST_CHANGE). Action Plan: Verifying.
Created attachment 86055 [details] Workaroun Waiting until workspace gets synchronized to proceed with marker updates causes workbench to hang. This a patch that does not allow for setting markers if worskpace is not synchronized. After "clean" project classpatch are build correctly (even on auto).
Created attachment 86093 [details] Patch attached The patch solves the problem, when the 'Build Automatically' is turned off. In this case we can import (without copying to the workspace) project A (the following error will appear: "Project A is missing required library: '\B\lib\util.jar") and later import (without copying to the workspace) project B (the error will disappear). The situation is slightly different when the 'Build Automatically' is turned on. In this case we can import (without copying to the workspace) project A (TWO errors will appear: first - "Project A is missing required library: '\B\lib\util.jar" and the second - "The project cannot be built until build path errors are resolved") and later import (without copying to the workspace) project B (the first error will disappear immediately but cleaning project A is required to remove the second error).
Created attachment 86316 [details] JDT/Core fix Note that the patch against Platorm/UI (from comment 14) is just a workaround. The bug is in JDT/Core. This patch should fix the problem.
Created attachment 86327 [details] Regression test
Fix and regression test released in R3_2_maintenance stream. Also released regression test in HEAD and R3_3_maintenance stream.
Verified.
