Community
Participate
Working Groups
3.2RC1 Create a Java project that has some errors in it, and you can see the markers in the editor and in the Problems views. Then right click on the project, select Properties > Builders, and turn off the Java Builder. Click OK. All the markers put in by the builder remain and there's no obvious way to get rid of them. I discovered this when trying to replace the Java Builder. In lieu of a patch here's the fix. In org.eclipse.jdt.internal.core.JavaProject, the deconfigure() method, after the Java builder has been deregistered all the project markers it might have put there should be deleted. I'm not sure if this is the complete set of markers but it should be something like this: public void deconfigure() throws CoreException { // deregister Java builder removeFromBuildSpec(JavaCore.BUILDER_ID); + + // remove orphaned markers + this.project.deleteMarkers(IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER, + true, IResource.DEPTH_INFINITE); }
+1 for 3.2RC2. Jerome - shouldn't it also clear all managed markers ?
Yes, managed markers should be deleted as well as BUILD_PATH_PROBLEM_MARKERs and TASK_MARKERs.
Actually, BUILD_PATH_PROBLEM_MARKERs are not created by the Java builder, and they should not be deleted. Since they indicate build path problems, they can have an impact on errors reported in the Java editor, independantly of the Java builder.
Ed, deconfigure() is called only if the Java nature is removed from the project. Removing the Java builder does not call deconfigure(). It triggers an IResourceDelta which doesn't contain the information that the builder was removed, only that the project was changed. So the fix is not as simple as this. Also this is not a regression since this scenario was never supported in previous releases. Propose to consider post 3.2. Is that ok with you ?
Agree for deferring, this isn't an immediate/trivial fix and we are closing already.
Will consider post 3.2. Workaround is to run Project > Clean (without building) before removing the Java builder.
Ah, you're right. It's ok to defer because I have a workaround. The workaround is that when I configure my own nature I'll remove the Java markers (because for my use case it doesn't make sense to have both the Java builder and my builder active at the same time). And maybe for a more complete fix, each builder should register the markers or marker types it creates, so when builders are removed the markers could be removed automatically. That would benefit all builders, not just the Java one.
See also bug 136337.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
