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:
- Open
plugin.xmlof theminimark.uiproject. Add the following extension to define aMinimarkMarker:<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>
- To use this marker when the error is created, instead of using
IMarker.PROBLEM, use its extension ID fromplugin.xmlin theprocessResource()method of theMinimarkVisitor://The following commented line needs to be removed /*IMarker marker = resource.createMarker(IMarker.PROBLEM);*/ IMarker marker = resource.createMarker( "com.packtpub.e4.minimark.ui.MinimarkMarker");
- At the start of the
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);
- Run the Eclipse instance and verify that as soon as some content is put in a
.minimarkfile that the errors are cleared. Delete the content, save the file, and the errors should reappear. - Finally, the editor doesn't show up warnings in the column. To make that happen, change the super class of
MinimarkEditorfromAbstractEditortoAbstractDecoratedTextEditor. 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.