Community
Participate
Working Groups
build I20040407 - UI and Text projects loaded from head, rest as external binaries - Project > Clean - Project > Build All - went away - saw the following in the log when I came back - note that I previously did have org.eclipse.core.runtime loaded from head, but deleted it a couple of days ago Not sure which project it was building. Might be good to indicate this in the log entries. Error Apr 09, 2004 12:40:40.505 JavaBuilder handling CoreException Java Model Exception: Java Model Status [org.eclipse.core.runtime does not exist.] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:532) at org.eclipse.jdt.internal.core.JavaModelManager.getPerProjectInfoCheckExistence(JavaModelManager.java:849) at org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo(JavaProject.java:1644) at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1689) at org.eclipse.jdt.internal.core.JavaProject.getRawClasspath(JavaProject.java:1675) at org.eclipse.jdt.internal.core.builder.JavaBuilder.isWorthBuilding(JavaBuilder.java:529) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:134) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:514) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607) at org.eclipse.core.runtime.Platform.run(Platform.java:524) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:140) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:227) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:168) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:197) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607) at org.eclipse.core.runtime.Platform.run(Platform.java:524) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:200) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:245) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:273) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:175) at org.eclipse.ui.actions.GlobalBuildAction$1.run(GlobalBuildAction.java:190) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:62)
The problem is due to a test project I have, which has a direct reference to org.eclipse.core.runtime (made before I deleted it). Here's its .classpath: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="/org.eclipse.swt"/> <classpathentry kind="src" path="/org.eclipse.jface"/> <classpathentry kind="src" path="/org.eclipse.core.runtime"/> <classpathentry kind="output" path=""/> </classpath>
We should add protection for a core exception in #isWorthBuilding.
Actually, before asking a prereq project for its classpath, we should first check whether it does exist.
Cannot reproduce... I cannot get past the initial 'isClasspathBroken' check since a prereq project is missing. Nick: Did you change any Build Path error/warning levels?
I have the defaults for the Build Path settings: Error, Error, Warning, Ignore. Pressing Restore Defaults doesn't change this (although it does clear the Filtered Resources field, which was previously set to *.launch).
Do you run with Auto-Build on?
Reproduced with Auto-Build turned off. The classpath error from the missing prereq project does NOT exist when the Build All happens.
Generally I have autobuild turned off. Sometimes I turn it on, but it was probabl off when I encountered this.
Found it... its caused by BuildManager.basicBuildClean private void basicBuildClean(IProject project, MultiStatus status) { try { //discard all problem markers in the project project.deleteMarkers(IMarker.PROBLEM, true, IResource.DEPTH_INFINITE); } catch (CoreException e) { status.merge(e.getStatus()); } } ------------ Because of this code, we lose the problem 'classpath.unboundProject'. The marker is a IJavaModelMarker.BUILDPATH_PROBLEM_MARKER, a subtype of the IMarker.PROBLEM. Also, you can duplicate this with Auto-Build on by doing a clean, thanks to the code above. 1. Create 2 projects 'A' & 'Missing'. Have 'A' depend on 'Missing'. 2. Delete 'Missing'. Get expected error, everything is fine. 3. Choose 'Clean...' -> the 'classpath.unboundProject' error is deleted & the build follows the stacktrace above. Moving to Platform/Core... not every problem is created during a build cycle. Clean cannot delete them.
Jeem, do you have a suggestion here? JDT core is relying on the build path problem marker, and they are broken when clean removes it. The marker is created based on information from a delta on the .classpath file, and they have no trigger to regenerate the marker.
I don't see any easy way out. Clean should not delete problem markers. The spec for IncrementalProjectBuilder.clean should say that deleting builder- generated markers and derived files is recommended (builder's responsibility).
Ok, that's what I'll do. Unfortunately we can no longer help users who have misbehaving builders, or have uninstalled builders that left behind markers on the project.
Fixed. Clean no longer deletes markers. I have entered bug 60822 for the Java builder to delete markers during clean.
