The current implementation has a flaw, in that it doesn't appear to fix the problems after they have been resolved. That's because the marker types are kept associated with a resource, even if that resource is changed. The reason this isn't seen in Java files is that the builder wipes out all (Java) errors prior to the start of a build, and then adds new ones as applicable. To avoid wiping out other plug-in's markers, each marker has an associated marker type. JDT uses this to distinguish between its markers and others contributed by different systems. This can be done for MinimarkMarkers
as well. Perform the following steps:
plugin.xml
of the minimark.ui
project. Add the following extension to define a MinimarkMarker
:<extension id="com.packtpub.e4.minimark.ui.MinimarkMarker"name="Minimark Marker"point="org.eclipse.core.resources.markers"> <persistent value="false"/> <super type="org.eclipse.core.resources.problemmarker"/> </extension>
IMarker.PROBLEM
, use its extension ID from plugin.xml
in the processResource()
method of the MinimarkVisitor
://The following commented line needs to be removed /*IMarker marker = resource.createMarker(IMarker.PROBLEM);*/ IMarker marker = resource.createMarker( "com.packtpub.e4.minimark.ui.MinimarkMarker");
processResource()
method, flush all the markers associated with the resource of this type: resource.deleteMarkers( "com.packtpub.e4.minimark.ui.MinimarkMarker",true, IResource.DEPTH_INFINITE);
.minimark
file that the errors are cleared. Delete the content, save the file, and the errors should reappear.MinimarkEditor
from AbstractEditor
to AbstractDecoratedTextEditor
. Run the Eclipse instance again. Now errors will be reported in the editor as well:Now the custom markers for the resource are being deleted at the start of a build and if there's a problem a marker will be automatically added. When the problem is resolved, the resource's markers are automatically deleted anyway.
In the deletion code, the boolean argument says whether to delete markers that are a subtype of that marker type or not. The second argument says what happens in the case that it's a folder or other container, and if deletion should recurse.
Generally, builders delete and create a specific type of problem marker so that they do not affect the other that may be associated with that resource. This allows other contributors (such as the spell checking editor) to raise warnings or informational dialogs that are not cleaned by a particular builder.
Fix the file detection so that it works out when the source file is really empty. Do this by using EFS
and the file's locationURI
to get a FileInfo
, which contains the file's size.