Can a single global inspection add problems for multiple groups?

Quick update...I tried to register an InspectionToolPresentation using the "presentation" attribute of the "globalInspection" EP, but I'm getting a ClassNotFoundException.  Looking at the classloader in use when that's instantiated in GlobalInspectionContextImpl.getPresentation(), it's the IDE's classloader/classpath, not the plugin's classloader/classpath.

This is similar to a problem I've been kicking around. I'm planning a group of inspections for unused elements in a namespace. I've been thinking about how to gather the information, which will come in a single pass over a file resolving everything in the file. This is a somewhat expensive operation even though it's only a single file. My plan was to store the results of the file sweep in user data on the file, and have different inspections which access that data. The tricky bit is how to synchronise the inspections with the data creation - probably I will have the first inspection which tries to access the data create it, and subsequent inspections will block until the creation is finished. I'm not sure how this might affect the inspection threading model though - opinions welcome.

It's not strictly related to your case, but perhaps you could use a similar idea - basically a single inspection result stored somewhere that multiple inspections access, and somehow delay later inspections until the data is ready?

Thanks, Colin.  I considered just such an option, but the issue is that I would be chasing a fast moving target in terms of the types of rules/violations coming from the external tool.  For now I've just incorporated the details into the inspection message in as concise a form as I can.  The end result is decent though far from perfect.  Hopefully at some point there will be support for a single inspection with more control over the presentation of the results (tree structure, node icon, message formatting, etc.).  It even looks like quite a bit of that is actually almost there already with the "presentation" attribute of the "globalInspection" EP (I just can't use it right now) and the "codeInspection.InspectionExtension" EP which just seems VERY unwieldy to implement with only a little potential progress toward the goal.

I'll be interested to know how it goes for you.  If I do find anything useful/productive, I'll post an update here.

Having a single inspection tool report for multiple categories is currently not possible. You will have to implement a separate inspection tool for each type of problem. This also allows the user to configure them separately. This is also how the Android Lint inspections are implemented in Android Studio for example.

Thanks, Bas.  Yes, that's what I found to be the case.  Unfortunately as mentioned above, I have no control over the set of rules in the external tools that I'm integrating (one is a PMD plugin and the other is an extension of ESLint), so creating and maintaining distinct inspection tools for each and every rule will be untenable over time.  As a result, for the moment I've just formatted the messages to contain the relevant details such as severity, category, etc.  Users seem to be quite pleased with the current state, so I'll probably leave it there for the moment and keep an eye on any enhancements in this area for more flexibility around formatting or perhaps even dynamically registering inspections at runtime.

Thanks again!

Bas, can you comment on the general feasibility of the approach I outlined above? If data has to be collected for a group of related inspections, is the best approach to have the first one calculate the data and the remaining ones block until that data is ready? Is there a better approach for this synchronisation?

Colin, sorry I don't know. Your approach may work. You will have to try it and see.

BTW vote for IDEA-142693 API for separating one inspection's results into several "virtual" inspections