Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-57427

Use warnings-next-generation instead of old plugins in pipeline-maven-plugin

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Use the warnings-ng-plugin instead of the old plugins.

        Attachments

          Activity

          Hide
          cleclerc Cyrille Le Clerc added a comment -

          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.

          Show
          cleclerc Cyrille Le Clerc added a comment - 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.
          Hide
          drulli Ulli Hafner added a comment -

          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?

          Show
          drulli Ulli Hafner added a comment - 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?
          Hide
          reitzmichnicht Michael Düsterhus added a comment -

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

          Show
          reitzmichnicht Michael Düsterhus added a comment - I would suggest to remove all warnings related publishers from the pipeline-maven plugin. Separation of concerns should be the design pattern here.
          Hide
          cleclerc Cyrille Le Clerc added a comment -

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

          Ulli Hafner 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).

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

          Michael Düsterhus 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.

          Show
          cleclerc Cyrille Le Clerc added a comment - > 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? Ulli Hafner 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). > Michael Düsterhus : I would suggest to remove all warnings related publishers from the pipeline-maven plugin. Separation of concerns should be the design pattern here. Michael Düsterhus 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.
          Hide
          drulli Ulli Hafner added a comment -

          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.

          Show
          drulli Ulli Hafner added a comment - 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.
          Hide
          reitzmichnicht Michael Düsterhus added a comment -

          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.

          Show
          reitzmichnicht Michael Düsterhus added a comment - 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.

            People

            • Assignee:
              cleclerc Cyrille Le Clerc
              Reporter:
              pmr Philipp Moeller
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: