Maven Project Info Reports Plugin
  1. Maven Project Info Reports Plugin
  2. MPIR-238

Dependency File Details section of the dependencies report shows 'target/classes' for reactor artifacts.

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.4
    • Fix Version/s: None
    • Component/s: dependency-info
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Generating the dependencies report in a multi-module project leads to incorrect entries in the 'Dependency File Details' section of the dependencies report. For example, the Maven Release Plugin Dependency File Details report contains the following entry:

      Filename Size Entries Classes Packages JDK Rev Debug
      maven-release-manager/target/classes - 0 0 0 - release

      Building the site of a single module ('mvn site' in that modules directory), the correct entries are shown.

        Issue Links

          Activity

          Hide
          Herve Boutemy added a comment - - edited

          The solution to MPIR-322 as it got committed is incorrect in my opinion

          +1, it's not the perfect and most generic solution

          things like mvn package|install|deploy clean site

          cleaning after compile then generating site is just a proof of the "it's not ideal" concept: but who wants to do that, not only to show that the MPIR-322 solution is only a workaround for core limitations?

          The same problem exists for artifacts not installed locally

          +1: I never said MPIR-322 is perfect
          a plugin can't fix a core issue: it only can sometime workaround it, like the great idea in MPIR-247 after fixing MNG-5568

          the more I work on m-site-p (and I really mean work on it), the more I see the limitations we have in Maven core for really supporting a lot of things such a plugin require, ie coordination of plugins in a lifecycle parallel to the standard build lifecycle to summarize the whole idea

          But m-site-p works not so bad for a long time

          Then even if I know that there are strong limitations that will require strong changes in Maven core, we'll have to live with limited workarounds to extend the "m-site-p works not so bad for a long time" mantra as much as possible instead of focusing only on "there are strong limitations that will require strong changes in Maven core"

          Show
          Herve Boutemy added a comment - - edited The solution to MPIR-322 as it got committed is incorrect in my opinion +1, it's not the perfect and most generic solution things like mvn package|install|deploy clean site cleaning after compile then generating site is just a proof of the "it's not ideal" concept: but who wants to do that, not only to show that the MPIR-322 solution is only a workaround for core limitations? The same problem exists for artifacts not installed locally +1: I never said MPIR-322 is perfect a plugin can't fix a core issue: it only can sometime workaround it, like the great idea in MPIR-247 after fixing MNG-5568 the more I work on m-site-p (and I really mean work on it), the more I see the limitations we have in Maven core for really supporting a lot of things such a plugin require, ie coordination of plugins in a lifecycle parallel to the standard build lifecycle to summarize the whole idea But m-site-p works not so bad for a long time Then even if I know that there are strong limitations that will require strong changes in Maven core, we'll have to live with limited workarounds to extend the "m-site-p works not so bad for a long time" mantra as much as possible instead of focusing only on "there are strong limitations that will require strong changes in Maven core"
          Hide
          Christian Schulte added a comment -

          There are ways to solve this without having to change the core and without having to work around anything. Just updating the reports expecting a packaged archive to @execute phase="package" will already make the core resolve to the jar instead of target/classes as expected. Meanwhile I've opened a pull request https://github.com/apache/maven/pull/32 to add the option mentioned above.

          Show
          Christian Schulte added a comment - There are ways to solve this without having to change the core and without having to work around anything. Just updating the reports expecting a packaged archive to @execute phase="package" will already make the core resolve to the jar instead of target/classes as expected. Meanwhile I've opened a pull request https://github.com/apache/maven/pull/32 to add the option mentioned above.
          Hide
          Herve Boutemy added a comment -

          Just updating the reports expecting a packaged archive to @execute phase="package" will already make the core resolve to the jar instead of target/classes as expected

          I see the idea
          I also know the problems with such a solution: see MJAVADOC-171 which is why reporting plugins which used to have such execution finally add new "-nofork" goals

          for https://github.com/apache/maven/pull/32, we need a MNG issue since it's a core fix
          and it will require core IT and discussions on dev@ IMHO: I think such a discussion will be useful but can be complex (since adding an option is just a workaround too, then I don't think it will be pleasant for everybody )

          I don't have time to do it at the moment, but I'm interested to work with other in january on that (which is a can of worms that we'll need to open one day or the other)

          Show
          Herve Boutemy added a comment - Just updating the reports expecting a packaged archive to @execute phase="package" will already make the core resolve to the jar instead of target/classes as expected I see the idea I also know the problems with such a solution: see MJAVADOC-171 which is why reporting plugins which used to have such execution finally add new "-nofork" goals for https://github.com/apache/maven/pull/32 , we need a MNG issue since it's a core fix and it will require core IT and discussions on dev@ IMHO: I think such a discussion will be useful but can be complex (since adding an option is just a workaround too, then I don't think it will be pleasant for everybody ) I don't have time to do it at the moment, but I'm interested to work with other in january on that (which is a can of worms that we'll need to open one day or the other)
          Hide
          Christian Schulte added a comment -

          (since adding an option is just a workaround too, then I don't think it will be pleasant for everybody )

          Absolutely. Some enhancements in Maven 3 made it misbehave in certain cases. An option to revert those enhancements temporarily is a work around for this. Retains backwards compatibility. I will open a new core issue for this.

          Show
          Christian Schulte added a comment - (since adding an option is just a workaround too, then I don't think it will be pleasant for everybody ) Absolutely. Some enhancements in Maven 3 made it misbehave in certain cases. An option to revert those enhancements temporarily is a work around for this. Retains backwards compatibility. I will open a new core issue for this.
          Hide
          Herve Boutemy added a comment -

          thank you Christian: I'll work on MNG-5738 in early january (if nobody beats me at it)

          Show
          Herve Boutemy added a comment - thank you Christian: I'll work on MNG-5738 in early january (if nobody beats me at it)

            People

            • Assignee:
              Unassigned
              Reporter:
              Christian Schulte
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: