One more thing: In class AbstractMavenReport, field 'reportOutputDirectory' is private (not protected), i.e. it cannot be updated independently by extending mojos. Using the setter method also updates 'outputDirectory' simultaneously. The latter is a protected field, BTW. Of course, the setter method could be overridden or the overriding class could somehow cater to the sacred knowledge of the side effect in 'setReportOutputDirectory'. Interestingly, Maven Javadoc Plugin's class JavadocReport simply defines its own private 'reportOutputDirectory' field, not extending AbstractMavenReport at all. I would, however, rather stick with the approach to use the abstract base class and extend it the right way, based on expert suggestions here.
-- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 20.10.2023 09:08 (GMT +07:00): > Hello. > > I am trying to improve a reporting mojo in a Maven plugin. The mojo > extends org.apache.maven.reporting.AbstractMavenReport. I recently > upgraded it to Doxia 2.0 - thanks again to Hervé B. and Michael O. for > their support - and cleaned out some cruft, removing redundant super > class fields and methods) in the mojo code. So far, so good. > > My question is about the different behaviour for configuring the report > output directory when starting the mojo directly as a Maven goal > compared to it being started during Maven site generation. The Javadoc > is helpful and explains: > > ------------------------------------------------------------------------ > > public abstract class AbstractMavenReport extends AbstractMojo > implements MavenMultiPageReport > { > /** > * The output directory for the report. Note that this parameter is > * only evaluated if the goal is run directly from the command line. > * If the goal is run indirectly as part of a site generation, the > * output directory configured in the Maven Site Plugin is used > * instead. > */ > @Parameter(defaultValue = "${project.reporting.outputDirectory}", > readonly = true, required = true) > protected File outputDirectory; > > ------------------------------------------------------------------------ > > I.e., if the user sets the directory as a plugin option, she is fine > when using the plugin directly. If she uses it as a reporting plugin for > site generation, she needs to set 'outputDirectory' in Maven Site > Plugin. But actually, that is not the right approach, because my > understanding is that 'outputDirectory' should rather set a base > directory for *all* reporting plugins, if the default target/site is not > OK. In that case, any plugin-specific output directory ought to be > interpreted as a subdirectory of the general reporting > 'outputDirectory', not simply be ignored. I saw that Maven Javadoc > Plugin has some logic that seems to handle that, using a separate > 'destDir' property to recalculate the output directory in a reporting > context. From class JavadocReport: > > ------------------------------------------------------------------------ > > /** > * @param theDestDir the destination directory > */ > public void setDestDir(String theDestDir) { > this.destDir = theDestDir; > updateReportOutputDirectory(reportOutputDirectory, theDestDir); > } > > private void updateReportOutputDirectory(File reportOutputDirectory, > String destDir) > { > if (reportOutputDirectory != null > && destDir != null > && !reportOutputDirectory.getAbsolutePath().endsWith(destDir)) > { > this.reportOutputDirectory = > new File(reportOutputDirectory, destDir); > } else { > this.reportOutputDirectory = > reportOutputDirectory; > } > } > > ------------------------------------------------------------------------ > > Different Maven plugins seem to handle this situation differently. Is > this the suggested, canonical approach? What do you think is a user's > expectation for multi-page report mojos extending AbstractMavenReport? > Certainly not that three conflicting reporting plugins have to argue > about which one can use Maven Site's 'outputDirectory' proprty for its > private purposes, leaving the other reporting plugins falsely > configured. Do all reporting plugins need to provide a separate > 'destDir' or 'reportingDir' property for that use case? WDYT? > > Sorry for asking a long-winded question, but I think it is important for > me to provide some context for the benefit of everyone trying to answer. > > Thanks in advance. Cheers --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
