Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: WID Development is trying to provide a quick fix for one of the Eclipse error markers to address a customer problem. The related PMR for WID is 68571,500,000. The Eclipse error marker text is: "The project cannot be built until its prerequisite XXX is built. Cleaning and building all projects is recommended" 1) We need to understand the various scenarios that can lead to this error being shown. Because it happens in the ambiguous case of "things get of of sync in the workspace," we have been unable to consistently reproduce. We are looking for a way to reverse engineer a test case so that WID development can create a quick fix for the marker. Can you provide a definition of when this error marker is shown? 2. If there's a particular Eclipse developer who would be able to answer questions and work with the WID developer on this, that name would be helpful. I can make the connection between the two parties (I'm with the WID SWAT team). More information: Background: The original customer complaint was about the fact that WID kicks of an incremental build of the workspace after a user selects a specific project(s) to build, and when build automatically is turned off. That's an expected behaviour with WID and not easily corrected. We determined that the root of the customer's grief was because they frequently see the error marker identified above, and then clean their entire workspace. Thus, when they choose to build a specific project, the subsequent incremental workspace build that WID kicks off builds the entire workspace. Since this is very large for the customer, it takes a long time (too long for them!). WID development proposed that we try to add a quick fix to this Eclipse error marker that would clean and build only the necessary subset of projects required to get the workspace back to a stable state. If we could do this, it would alleviate the problem of too-long incremental builds.
This error marker comes from JDT core, so I'll move there for more detailed answers to 1) and 2). This error typically means that someone is attempting to build a project, but that project has dependencies on other projects that have not yet been built. This can happen if someone programmatically calls IProject#build on a project without first building prerequisites. So, the fact that you are seeing this error could possibily indicate a misuse of IProject#build in WID. The org.eclipse.ui.actions.BuildAction class has code that traverses the prerequisites of a project and ensures the projects are built in the correct order, so you should not see this problem when using the "Build Project" command in the Project menu. Note another potential cause is a manually configured build order that is incorrect (see the Build Order preference page). If you have a manual build order such that prerequisite projects are not ordered correctly, you would get this error. If you had such a quick fix, this code is likely what you need.
This kind of error is just a way for the Java builder to trap out in case of major inconsistency in the workspace build state. The Java builder is performing across all projects (one at a time) following the build order. The build order is determined by the project dependencies (if project A requires project B, then B should be built first). This allows downstream projects to consume the binaries produces when compiling upstream projects first. If at some point, a given project notices that an upstream project has not been built yet, then it will abort the build process with such an error marker ("The project cannot be built until its prerequisite XXX is built. Cleaning and building all projects is recommended"). In comment 1, John explained how this can be reproduced intentionally when user/tool is only building selected projects. This is definitely a possibility; another one is that there are cycles in project dependencies, and that the cycle support is not properly enabled. Another possibility is that you are seeing the consequence of a bug in JDT/Core. The build order is inferred after considering all respective project buildpathes, and linearizing the project dependencies. Due to the concurrent nature of buildpath initialization, at times we identified and addressed some classpath computing issues which could have lead to inconsistent classpaths in the end. Please interact with Jerome to find out whether this is what you saw or not. One important factor to work through this is for you to gather steps to reproduce.
Once you can reproduce it, you may want to try a JDT/Core 3.2.x patch (>3.2.2) to see if you are facing some of these issues which we have backported fixes for in 3.2 stream: bug 216569, bug 214981 or bug 162054.
JDT/Core 3.2.8 patch is available at: http://www.eclipse.org/jdt/core/r3.2/index.php#UPDATES if you need it.
Thanks everyone for all the feedback and explanation. It leads me to think that there is a bug buried somewhere here, since it doesn't sound like a WID end-user, doing build through Project->build project, should ever see this error marker. At the moment, we have no scenario to reproduce. This only happens sporadically for the customer (about once every two weeks). However, I've now heard that if they see it again, they believe that they could tell us the steps that they used to create it. I would therefore like to wait until they see it again, and try to capture reproducible steps. Then I think we can get somewhere. So, we're on hold right now. The customer will be starting development again Nov 1, and hopefully we will see the issue within two weeks and gather some steps. As soon as that happens, I'll update the bug. Thanks.
Julie, would you have any news from your customer?
I was able to reproduce this problem in a debug environment. Here's my analysis. We have an authoring project, let's call it "AuthProj". In one of the builders for this project, we generate two other projects, let's call them "GenProj1" and "GenProj2". The build order seen in the debugger is GenProj1 -> AuthProj -> GenProj2. If I delete the GenProj's, then clean AuthProj, what I see in the debugger is that the build order above is seen in the builder code (BuildManager.basicBuildLoop()). This code also checks to ensure that the project being built is accessible. First up is "GenProj1", which doesn't exist, so it doesn't get built. Next, "AuthProj" is built, which generates the "GenProj"s. "GenProj2" then gets built... however JDT does a check to ensure it's prereq is built, but it isn't because it didn't exist yet in this build loop, so it creates the error marker. So what's wrong? In my opinion, the IResource framework is incorrect. The API for Workspace.getBuildOrder() says "closed or non-existent projects are ignored and not included in the result". Obviously, this statement is being broken here. The build immediately after the delete includes two projects that don't exist. I changed Resource.delete() to include these lines: if(this instanceof IProject) workspace.flushBuildOrder(); and it fixed the problem. The gen'd project are then built in the same build loop, as expected. I see that Project.open() and Project.close() call the workspace.flushBuildOrder() method. So I think the deletion case is simply missing.
Thanks for this analysis Grant!
I noticed the target milestone has not been set. The latest version of our adopting product is based on 3.4.2. We require the fix to be committed in 3.4.2
FYI, customer will begin putting WID 6.1.2 on their test systems by mid-Feb, so if we could get a fix by then, it would be ideal! Thanks.
+1 for 3.4.2 (assuming this is the right fix)
Fix released to HEAD and 3.4.x stream.
Seeing it in 3.8.1 release Build id# M20120914-1540
(In reply to comment #13) > Seeing it in 3.8.1 release > Build id# M20120914-1540 The 3.8 stream is done. If you see this in 4.3 or newer, then please open a new bug with steps to reproduce.
