It would be nicer if e.g. $build/analysisPlugins/api/xml were bound to something that simply enumerated the plugin IDs. (Alternately, this API object could directly list all the results under e.g. <findbugsResult>.)

I think the latter one is already available when using the analysis-collector plug-in that shows the aggregation of all plug-ins:
http://www.faktorzehn.org:8081/view/Jenkins/job/Jenkins%20Analysis%20Plug-ins/300/analysisResult/api/xml
Or do you need the individual results?

That might work when that plugin is installed, but for e.g. https://builds.apache.org/job/Ant_Nightly/lastSuccessfulBuild/ there is no such API object. Would prefer something built in to the Analysis Core module so it is always available.

Ok, I see. Currently the analysis-core plug-in does not know which plug-ins are actually running (that was the reason for the collector plugin).

Ah. It seems that it should be possible to find what Action objects (right?) are being exposed by the job, but if not then I guess this has to be closed and I just request sites to run the collector plugin.

I can check which action objects are available and test for all results if they are deriving from a base class of analysis-core. That should work.

However, the longer I am thinking about it: maybe I should move all the code of the analysis collector plug-in code to analysis core and provide an extension point that the individual plug-ins implement. Then core needs not to know anything about the individual plug-ins but still can present an aggregation...

Right, an extension point is how I would have expected it to work already.

Behavioral compatibility might be tricky, i.e. in case one of the plugins is updated but not core, or vice-versa.