[ 
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778891#comment-17778891
 ] 

Alexander Kriegisch edited comment on MSHARED-1327 at 10/24/23 2:05 AM:
------------------------------------------------------------------------

[~michael-o], if  {{${project.build.directory}/reports}} had always been some 
kind of de facto standard, I would agree. It would surely be nice to tuck away 
reports in some kind of standard directory. But the precedent set by other 
plugins like Maven Javadoc is to actually "pollute" the {{target}} directory. 
This is not perfect, but people can live with it. Fixing the default to point 
to the build directory for stand-alone is already a breaking change that needs 
to be mentioned in the release notes and maybe even in the plugin parameter 
documentation, because it will affect plugins extendig the abstract report 
class. But adding {{/reports}} would be an even harsher change that would never 
reach plugins like Javadoc, because they do not use the base class. That could 
lead to some kind of "schism" between plugins extending {{AbstractMavenReport}} 
and others implementing the corresponding interfaces themselves. Therefore, if 
I were you, I would be careful about the {{/reports}} idea.


was (Author: kriegaex):
[~michael-o], if  {{${project.build.directory}/reports}} had always been some 
kind of de facto standard, I would agree. It would surelybe nice to tuck the 
reports away in some kind of standard directory. But the precedent set by other 
plugins like Maven Javadoc is to actually "pollute" the {{target}} directory. 
This is not perfect,but people can live with it. Fixing the default to point to 
the build directory for stand-alone is already a breaking change that needs to 
be mentioned in the release notes and maybe even in the plugin parameter 
documentation, because it will affect plugins extendig the abstract report 
class. But adding {{/reports}} would be an even harsher change that would never 
reach plugins like Javadoc, because they do not use the base class. That could 
lead to some kind of "schism" between plugins extending {{AbstractMavenReport}} 
and others implementing the corresponding interfaces themselves. Therefore, if 
I were you, I would be careful about the {{/reports}} idea.

> Change output directory default in AbstractMavenReport
> ------------------------------------------------------
>
>                 Key: MSHARED-1327
>                 URL: https://issues.apache.org/jira/browse/MSHARED-1327
>             Project: Maven Shared Components
>          Issue Type: Improvement
>          Components: maven-reporting-impl
>    Affects Versions: maven-reporting-impl-4.0.0-M11
>            Reporter: Alexander Kriegisch
>            Assignee: Michael Osipov
>            Priority: Major
>             Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead 
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from 
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution, 
> a plugin should not mess with Maven Site's default directory. Imagine a 
> situation in which each module should get its own, self-consistent report 
> when called stand-alone, but the site should contain an aggregate with a 
> different structure or maybe no report from that plugin at all. The default 
> would then pollute the site directory. This is why on the ML I asked you 
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class 
> field by another {{@Parameter}} annotation on a setter in a subclass it is 
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not 
> use the abstract base class, implements the default correctly: build dir for 
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site 
> generation context, the reporting base directory will be set here 
> automatically without any further changes due to:
> {code:java}
>     @Override
>     public void setReportOutputDirectory(File reportOutputDirectory) {
>         this.reportOutputDirectory = reportOutputDirectory;
>         this.outputDirectory = reportOutputDirectory;
>     }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to