[
https://jira.codehaus.org/browse/MPIR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359267#comment-359267
]
Herve Boutemy edited comment on MPIR-238 at 12/17/14 9:10 PM:
--------------------------------------------------------------
bq. The solution to MPIR-322 as it got committed is incorrect in my opinion
+1, it's not the perfect and most generic solution
bq. 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?
bq. 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"
was (Author: hboutemy):
bq. The solution to MPIR-322 as it got committed is incorrect in my opinion
+1, it's not the perfect and most generic solution
bq. 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?
bq. 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
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"
> Dependency File Details section of the dependencies report shows
> 'target/classes' for reactor artifacts.
> --------------------------------------------------------------------------------------------------------
>
> Key: MPIR-238
> URL: https://jira.codehaus.org/browse/MPIR-238
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-info
> Affects Versions: 2.4
> Reporter: Christian Schulte
> Priority: Minor
>
> 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|http://maven.apache.org/plugins/maven-release-plugin/dependencies.html#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.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
