Maven
  1. Maven
  2. MNG-4075

Tone down warnings about reactor dependencies that don't have an associated file

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.1.0
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      currently this is logged to the WARNING level, but it can be disquieting without causing any real problems. I'm not entirely sure how these messages come up during the clean phase, but at least in the CXF project, they definitely seem to.

      We should tone them down to the DEBUG log level for now, unless/until we can find a way of being certain they're going to cause a problem.

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          I'm not entirely sure how these messages come up during the clean phase

          DefaultLifecycleExecutor.constructLifecycleMappings() iterates over all build plugins and resolves their plugin JAR. And the cxf-parent defines an execution of cxf-xml2fastinfoset-plugin:$

          {project.version}

          which is part of the reactor but won't be build during "clean".

          Show
          Benjamin Bentmann added a comment - I'm not entirely sure how these messages come up during the clean phase DefaultLifecycleExecutor.constructLifecycleMappings() iterates over all build plugins and resolves their plugin JAR. And the cxf-parent defines an execution of cxf-xml2fastinfoset-plugin:$ {project.version} which is part of the reactor but won't be build during "clean".
          Hide
          Benjamin Bentmann added a comment -

          Hm, would it maybe make sense to distinguish between plugin artifacts and regular project dependencies here? For the case reported here, the warning is apparently oversized since the plugin is not actually used in the build. But for regular dependencies used to setup compile/test class paths I still believe it's right to inform the user that the class path does not reflect the current reactor output.

          Another/additonal option would be to reduce the warning itself to a single line and move only the detail output to debug level.

          Show
          Benjamin Bentmann added a comment - Hm, would it maybe make sense to distinguish between plugin artifacts and regular project dependencies here? For the case reported here, the warning is apparently oversized since the plugin is not actually used in the build. But for regular dependencies used to setup compile/test class paths I still believe it's right to inform the user that the class path does not reflect the current reactor output. Another/additonal option would be to reduce the warning itself to a single line and move only the detail output to debug level.
          Hide
          Dan Tran added a comment -

          the warnings are also found on eclipse:eclipse invocation

          Show
          Dan Tran added a comment - the warnings are also found on eclipse:eclipse invocation
          Hide
          John Casey added a comment -

          If we think it's a valuable thing to warn about sibling artifacts used for dependencies, that assumes those dependencies might have changed, which might change the compile or test results of the project currently being built. These are relatively easy to see, since they will likely stop the build. They may not be simple to debug without a message like this, but fundamentally this is a slightly less dangerous state of affairs than the following:

          If a plugin has been updated yet isn't used for the current build, the old copy may inject very subtle errors into the final project artifact, which could actually push off the discovery of this error to some point outside the build...even to the production runtime, if integration tests aren't run on that artifact. Same goes for build extensions.

          If we dial down this message for plugins, there should be no problem doing so for dependencies. Maybe a better solution would be to find a way to avoid using plugin/extension artifacts from projects in the reactor, that cannot be found in the reactor...I'm not sure how to do this for extensions, but for plugins (that don't use the extensions == true flag) we might use a just-in-time approach to loading the plugin artifact itself...

          I'll turn down this error message to debug log-level for now, but open a new issue for later to review the plugin/extension problem outlined above.

          Show
          John Casey added a comment - If we think it's a valuable thing to warn about sibling artifacts used for dependencies, that assumes those dependencies might have changed, which might change the compile or test results of the project currently being built. These are relatively easy to see, since they will likely stop the build. They may not be simple to debug without a message like this, but fundamentally this is a slightly less dangerous state of affairs than the following: If a plugin has been updated yet isn't used for the current build, the old copy may inject very subtle errors into the final project artifact, which could actually push off the discovery of this error to some point outside the build...even to the production runtime, if integration tests aren't run on that artifact. Same goes for build extensions. If we dial down this message for plugins, there should be no problem doing so for dependencies. Maybe a better solution would be to find a way to avoid using plugin/extension artifacts from projects in the reactor, that cannot be found in the reactor...I'm not sure how to do this for extensions, but for plugins (that don't use the extensions == true flag) we might use a just-in-time approach to loading the plugin artifact itself... I'll turn down this error message to debug log-level for now, but open a new issue for later to review the plugin/extension problem outlined above.
          Hide
          John Casey added a comment -

          now output just a small one-liner warning in recognition of the dangers described in MNG-4081. If you use -X you'll see a fair amount more information, and it'll be a little more prominent.

          Show
          John Casey added a comment - now output just a small one-liner warning in recognition of the dangers described in MNG-4081 . If you use -X you'll see a fair amount more information, and it'll be a little more prominent.

            People

            • Assignee:
              John Casey
              Reporter:
              John Casey
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: