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

          Issue Links

            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.
            Hide
            falcon benoit guerin added a comment - - edited

            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

            Ulli Hafner Michael Düsterhus what do you thing about this ?

            Show
            falcon benoit guerin added a comment - - edited 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 Ulli Hafner Michael Düsterhus what do you thing about this ?
            Hide
            drulli Ulli Hafner added a comment -

            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.

            Show
            drulli Ulli Hafner added a comment - 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 .

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              pmr Philipp Moeller
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated: