I like your proposal: if there is one of the supported static analysis tools invoked in maven (e.g. spotbugs-maven-plugin:3.1.12:spotbugs) then you automatically call a corresponding recordIssues step in the warnings plugin (well actually the warnings plugin will implement the extension point Cyrille mentioned above). There you can set the properties that are defined in the Maven pom. No other configuration of the warnings plugin will be possible. And if someone wants to use the configuration options of the warnings plugin, then the automatic default call must be deactivated with a flag in withMaven.

I would like to work on this but before submit my point of view to be sure I will be in the right direction ...

Maven is all about convention about configuration and as an end user I love withMaven in pipelines because it ensure to me that whereever my code is built (on controller, bare agent, docker agent ...), it will always build with the version of Maven I specify, with the Maven settings I want, and do things automagically for me (publish junit reports, jacoco coverage ...) just because I have the good plugins in my maven build, and the good jenkins ones to integrates results.

For me, this plugin is here to call other plugins for reporting, with the good context, detected from mojos reports during the build. And so, as an end user, I do not have to care to call junit(), publishCoverage() or recordIssues() myself, with a configuration that would be a duplicate from my pom.xml : convention over configuration

But now, if you are unhappy with the default behaviour of withMaven you can launch it with its publishers explicity disabled, and then call others native steps by your own, with the right configuration

drulli reitzmichnicht what do you thing about this ?

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.

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.

> 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.

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?

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.