Re: How to set default directories when developing a reporting plugin?
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
[RESULT] [VOTE] Retire Maven Docck Plugin
Hi, The vote has passed with the following result: +1 (binding): Olivier Lamy, Sylwester Lachiewicz, Michael Osipov, Tamás Cservenák, Maarten Mulders, Karl Heinz Marbaise, Benjamin Marwell, Henning Schmiedehausen, Slawomir Jaranowski +1 (non binding): Enrico Olivelli I will continue with the steps required to retire this plugin. -- Sławomir Jaranowski
Re: [VOTE] Retire Maven Docck Plugin
+1 wt., 17 paź 2023 o 00:50 Slawomir Jaranowski napisał(a): > Hi, > > - Last release was in 2015 > - use Maven 2.2.1 > - we have a Maven Plugin Tools - which should be one project for build and > check Maven plugins > - no active development ... > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDOCCK%20AND%20(%20resolution%20%3D%20Unresolved%20OR%20fixVersion%20%3D%203.0.0) > - no working with current plugins > > I therefore propose that we retire maven-docck-plugin - > https://maven.apache.org/plugins/maven-docck-plugin/ > > If this vote is successful I will make one final release of the plugin, > making it clear on the plugin site that it has been retired. > After that the source code will be moved into read-only mode. > > The process for retiring a plugin is described here: > https://maven.apache.org/developers/retirement-plan-plugins.html > > The vote is open for 72 hours. > > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > [1] > > -- > Sławomir Jaranowski > > -- Sławomir Jaranowski
RE: How to set default directories when developing a reporting plugin?
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
