Details

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.

Activity

The cause is class 'org.apache.maven.ReactorReader' falling back to returning directories when the 'compile' phase has completed which is the case for various report plugins marked '@execute phase="generate-test-sources"'. MPIR-238.patch contains a patch for the dependencies report adding '@execute phase="package"' to make the reactor reader stop returning directories. MPIR-238-ReactorReader.patch contains a patch for that class to not resolve to directories when not executing the default lifecycle.

Christian Schulte
added a comment - 28/Dec/11 2:47 PM - edited The cause is class 'org.apache.maven.ReactorReader' falling back to returning directories when the 'compile' phase has completed which is the case for various report plugins marked '@execute phase="generate-test-sources"'. MPIR-238 .patch contains a patch for the dependencies report adding '@execute phase="package"' to make the reactor reader stop returning directories. MPIR-238 -ReactorReader.patch contains a patch for that class to not resolve to directories when not executing the default lifecycle.

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"

Herve Boutemy
added a comment - 17/Dec/14 9:06 PM - 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"

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.

Christian Schulte
added a comment - 17/Dec/14 9:19 PM 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.

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)

Herve Boutemy
added a comment - 17/Dec/14 9:40 PM 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)

(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.

Christian Schulte
added a comment - 17/Dec/14 9:58 PM
(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.