The is a challenge of required version of jenkins-core ond of some key plugins.
warnings-ng requires more recent than what we would like to support.

warnings-ng is a great opportunity to simplify the configuration and usage of withMaven solving many problems of collecting reports at once when so far, we have to rely on many plugins to do this job.

Wouldn't it make sense to provide an extension point in the pipeline-maven-plugin so I can provide an implementation in the warnings plugin that gets automatically hooked in?

I would suggest to remove all warnings related publishers from the pipeline-maven plugin. Separation of concerns should be the design pattern here.

> Wouldn't it make sense to provide an extension point in the pipeline-maven-plugin so I can provide an implementation in the warnings plugin that gets automatically hooked in?

drulli with pleasure, there is already the "org.jenkinsci.plugins.pipeline.maven.MavenPublisher" and the "org.jenkinsci.plugins.pipeline.maven.publishers.AbstractHealthAwarePublisher" for the plugins related to analysis-core.

What would be the desired APIs? My understanding is that publishing quality reports requires primarily to access to the execution details of the maven mojos executed in a Maven build.
The existing API based on an XML document is probably way too low level for you ("org.jenkinsci.plugins.pipeline.maven.MavenPublisher#process(StepContext context, Element mavenSpyLogsElt)").
Note that I am introducing on Object Oriented model of the execution of Mojo executions for JENKINS-56448 (Enable Module Builds view for withMaven Pipeline builds).

> reitzmichnicht: I would suggest to remove all warnings related publishers from the pipeline-maven plugin. Separation of concerns should be the design pattern here.

reitzmichnicht can you please detail why you are reluctant to automatically detect Maven build phases that generated reports that we can collect in Jenkins?
My finding is that many people under use Jenkins reporting capabilities due to the boilerplate to collect all the reports.

There is already the "org.jenkinsci.plugins.pipeline.maven.MavenPublisher" and the "org.jenkinsci.plugins.pipeline.maven.publishers.AbstractHealthAwarePublisher" for the plugins related to analysis-core.
What would be the desired APIs? My understanding is that publishing quality reports requires primarily to access to the execution details of the maven mojos executed in a Maven build.
The existing API based on an XML document is probably way too low level for you ("org.jenkinsci.plugins.pipeline.maven.MavenPublisher#process(StepContext context, Element mavenSpyLogsElt)").

I haven't yet thought about the details of an API and did not look at your existing code yet. But from the old maven plugin I think it would make sense, that a plugin can register for a mojo execution event (e.g. spotbugs-maven-plugin:3.1.12:spotbugs). (It would make sense to support wildcards here for version and goal.). If the event occurs, I need the corresponding part of the POM as an event parameter. From this parameter I can configure the correct values for my existing publisher.

But as Michael already said, maybe it would be much simpler, if we remove all the recorders and let pipeline authors simply add the corresponding recordIssues step right after the withMaven call. Because with your approach I need to write yet another duplicate class that provides all the properties of the warnings publishers (and there are a lot). The only benefit of an automatic integration is that pipeline authors do not need to specify the filename of the report again.

The warnings-ng plugin is so powerful with configuration options that it doesn't make sense to duplicate these options in the publishers. Also it is often needed to collect warnings from multiple maven runs.