Best way to add/remove errors for a directory in the Problems View?

My custom language plugin sends the source to a remote system for compilation.  Warnings and errors are reported in response with information about the corresponding file, line/column numbers, warning/error message, etc.  I use that information to add annotations in the editor window and to add messages to the Problems View.  I clear both of those when the file is next changed assuming the user is fixing the issue(s).  That's all been working very well for a while.

Now I'm adding a new feature to the plugin that allows users to work with local archive files in an exploded fashion.  When these exploded archives are sent to the server, I automatically recreate the archive before sending.  Again, that all works well.  When the server reports warnings or errors about these archives, there's no corresponding archive file in the file system because the developer is working against an exploded version.  So basically the error is reported for something like myBundle.resource, but locally there's a directory called myBundle with the exploded contents of that archive resource.  I'm currently adding the warning or error for the root directory.  This shows up fine in the Problems View and gives feedback to the user that the deployment for that exploded archive failed and why.

The issue I'm having is that I can't *remove* the Problems View messages for these directories.  I'm calling ProblemsView.clearOldMessages() with a OneProjectItemCompileScope built around the virtual file for the directory.  Tracing that into ProblemsViewImpl.cleanupChildrenRecursively(), I'm seeing that the reported message is being processed as a GroupingElement with no children, so the element is never removed from the view.

Any thoughts on how I can remove these items from the Problems View after successfully adding them?  Am I reporting them improperly for a directory?  If so, any tips on how I should be reporting them?

Thanks in advance!

1 comment
Comment actions Permalink

I have a little more information to share, and I've created a workaround, but I'm still curious whether there's a better way.  Basically the reason the directory was being ignored for removal is because of the implementation of OneProjectItemCompileScope.belongs(String url).  For a directory, the URL of the test item must be start with the directory's URL with a trailing slash.  Obviously the URL of the directory itself doesn't.  My workaround is to subclass OneProjectItemCompileScope and override belongs() to see if the directory is a root directory for one of my exploded archives, and if so to look for an exact comparison.  Otherwise I'm delegating to the base implementation.  It works, and it narrows the scope of the specialization to exactly my use case, but it still feels like there's probably a better way to do it.

0

Please sign in to leave a comment.