Uploaded image for project: 'Maven Artifact Plugin'
  1. Maven Artifact Plugin
  2. MARTIFACT-60

artifact:3.5.0:check-buildplan is too chatty by default

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.5.0, 3.5.1
    • 3.5.2

    Description

      Running the plugin is too chatty by default, for example, I don't need everything that's NOT wrong. Just tell me what's wrong or nothing:

      [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
      [INFO] no known issue with org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
      [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
      [INFO] no known issue with org.apache.maven.plugins:maven-artifact-plugin:3.5.0
      [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
      [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
      [INFO] no known issue with org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
      [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
      [INFO] no known issue with org.apache.maven.plugins:maven-resources-plugin:3.3.1
      [INFO] no known issue with org.apache.maven.plugins:maven-compiler-plugin:3.13.0
      [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>= 5.1.9)
      [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
      [INFO] no known issue with org.apache.maven.plugins:maven-surefire-plugin:3.2.5
      [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0 (>= 3.2.0)
      [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
      [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1 (>= 3.2.1)
      [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
      [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
      [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>= 1.0.0.Final)
      [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
      [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
      

      Either say nothing or, if you must, perhaps a single log event:
      "No issues found in 16 plugins." Note that sentences should start with a capital letter.

      The current info would be fine at the debug logging level IMO.

      Attachments

        Issue Links

          Activity

            YW & TY as well 😊

            ggregory Gary D. Gregory added a comment - YW & TY as well 😊
            githubbot ASF GitHub Bot added a comment -

            hboutemy commented on PR #32:
            URL: https://github.com/apache/maven-artifact-plugin/pull/32#issuecomment-2053692701

            perfect, thank you

            githubbot ASF GitHub Bot added a comment - hboutemy commented on PR #32: URL: https://github.com/apache/maven-artifact-plugin/pull/32#issuecomment-2053692701 perfect, thank you
            githubbot ASF GitHub Bot added a comment - hboutemy merged PR #32: URL: https://github.com/apache/maven-artifact-plugin/pull/32
            ggregory Gary D. Gregory added a comment - Hi All, I propose https://github.com/apache/maven-artifact-plugin/pull/32
            githubbot ASF GitHub Bot added a comment -

            garydgregory opened a new pull request, #32:
            URL: https://github.com/apache/maven-artifact-plugin/pull/32

            Sample output from Apache Commons CLI
            [INFO] -

            githubbot ASF GitHub Bot added a comment - garydgregory opened a new pull request, #32: URL: https://github.com/apache/maven-artifact-plugin/pull/32 Sample output from Apache Commons CLI [INFO] -

            For a bit of context, I think that once a project opens itself up to patches and PRs from the world at large, a CI should check everything, especially when it is inexpensive.

            ggregory Gary D. Gregory added a comment - For a bit of context, I think that once a project opens itself up to patches and PRs from the world at large, a CI should check everything, especially when it is inexpensive.
            hboutemy Herve Boutemy added a comment -

            I feel people bind this goal in their normal build lifecycle, in which case I understand it is found very chatty

            when I wrote it, this goal has been intended for CLI use, as checking on every build does not make much sense to me: this goal was written to do the first Reproducible Builds activation easily with fast CLI feedback and fix easy-fixable issues in pom.xml immediately. Once it's done, remaining issues are much more precise than just a plugin version: this goal won't help much any more, only comparison and human dive into "why is there a difference?", with a human brain to track root cause.

            I'm not clear if we should fight the lifecycle bound approach: what I've learn over time is that fighting users is a lost game, users are too many, it's much easier to adapt a little bit when it's not hard = this case.

            perhaps this is a natural expectation from users: I must admit that even in my expected CLI usage, seeing a wide list of non-problems makes it hard to dive.

            Making by default a summary and eventually a verbose option makes sense

            (in addition, when I wrote the goal, "mvn builplan:list" was not well known, I needed to show even to myself that this goal was filtering on this list: nowadays, this goal is well know to everybody, my intent is probably not valid any more)

            +1 to do that

            hboutemy Herve Boutemy added a comment - I feel people bind this goal in their normal build lifecycle, in which case I understand it is found very chatty when I wrote it, this goal has been intended for CLI use, as checking on every build does not make much sense to me: this goal was written to do the first Reproducible Builds activation easily with fast CLI feedback and fix easy-fixable issues in pom.xml immediately. Once it's done, remaining issues are much more precise than just a plugin version: this goal won't help much any more, only comparison and human dive into "why is there a difference?", with a human brain to track root cause. I'm not clear if we should fight the lifecycle bound approach: what I've learn over time is that fighting users is a lost game, users are too many, it's much easier to adapt a little bit when it's not hard = this case. perhaps this is a natural expectation from users: I must admit that even in my expected CLI usage, seeing a wide list of non-problems makes it hard to dive. Making by default a summary and eventually a verbose option makes sense (in addition, when I wrote the goal, "mvn builplan:list" was not well known, I needed to show even to myself that this goal was filtering on this list: nowadays, this goal is well know to everybody, my intent is probably not valid any more) +1 to do that
            michael-o Michael Osipov added a comment -

            Makes sense. hboutemy, WDYT?

            michael-o Michael Osipov added a comment - Makes sense. hboutemy , WDYT?

            People

              hboutemy Herve Boutemy
              ggregory Gary D. Gregory
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: