Hello Michael, hello community.
I have decided to actually change the plugin's behaviour the way I
described:
-- I overrode the default value of AbstractMavenReport.outputDirectory
[1] by defining a setter method and adding a @Parameter annotation,
specifying ${project.build.directory} as the base direcory for the
report, because this is what I want to use when the mojo is
executed directly. The abstract super class defaults to
${project.reporting.outputDirectory}, which is IMO suboptimal. In a
site generation context, the report directory is set automatically
anyway, because AbstractMavenReport.setReportOutputDirectory, as
mentioned in my original message, sets both reportOutputDirectory
and outputDirectory. BTW, is this "trick" to override an inherited
property correct? Is there a canonical way to do that?
-- Then, I introduced a new reportDirectory [2] property, whis is just
a String, not a File. It specifies the subdirectory to be appended
to outputDirectory [3]. This works in both use cases, stand-alone
mojo execution and site generation.
-- Hence, it is now possible to configure the base directory and the
subdirectory name separately: The base directory is set in the
identically named property outputDirectory, either in the plugin or
in Maven Site, depending on the use case. The subdirectory is set
in the new reportDirectory property. I.e., reports will end up in
the following directories:
** without configuration, stand-alone:
target/aspectj-report
** without configuration, site generation:
target/site/aspectj-report
** custom base directory, stand-alone: e.g.
my-target/aspectj-report
** custom base directory, site generation: e.g.
target/my-site/aspectj-report
** custom subdirectory, stand-alone: e.g.
target/my-aspectj-report
** custom subdirectory, site generation: e.g.
target/site/my-aspectj-report
** custom base + subdirectory, stand-alone: e.g.
my-target/my-aspectj-report
** custom base + subdirectory, site generation: e.g.
target/my-site/my-aspectj-report
Notably, the custom base directory for site generation should work
for all plugins playing nicely, e.g. Javadoc or (now after my
change) AspectJ. See the integration tests [4] for examples, namely
CreateReport* test cases for stand-alone and CreateSite* ones for
site generation use cases. For each test case, compare the
differences in Maven Site and AspexctJ Maven settings and the
corresponding checks in verify.groovy.
[1]
https://github.com/dev-aspectj/aspectj-maven-plugin/blob/9f2d0e97ed963c2b69a7fdf731a4c919a6bb56ef/src/main/java/org/codehaus/mojo/aspectj/AjcReportMojo.java#L90-L106
[2]
https://github.com/dev-aspectj/aspectj-maven-plugin/blob/9f2d0e97ed963c2b69a7fdf731a4c919a6bb56ef/src/main/java/org/codehaus/mojo/aspectj/AjcReportMojo.java#L57-L67
[3]
https://github.com/dev-aspectj/aspectj-maven-plugin/blob/9f2d0e97ed963c2b69a7fdf731a4c919a6bb56ef/src/main/java/org/codehaus/mojo/aspectj/AjcReportMojo.java#L255
[4] https://github.com/dev-aspectj/aspectj-maven-plugin/tree/main/src/it
--
Alexander Kriegisch
https://scrum-master.de
Michael Osipov schrieb am 22.10.2023 01:17 (GMT +07:00):
>
>
> On 2023/10/20 02:08:25 Alexander Kriegisch wrote:
>> 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.
>
> This is, indeed, a good question. I have stumbled about similar during
> Doxia 2.0.0 work, but didn't dare to touch it because I didn't want to
> open too many construction sites. Let me go through to get a better
> understanding.
> Regarding Javadoc Plugin: I don't know whether is the perfect external
> reporting plugin because it does not inherit from AbstractMavenReport.
>
> M
> ��Т?????????????????????????????????????????????????????????????????????ХF?V?7V'67&?&R?R???âW6W'2?V?7V'67&?&T?fV??6?R??&pФf?"FF?F????6????G2?R???âW6W'2ֆV??fV??6?R??&p?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
