[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482931#comment-17482931
]
Herve Boutemy edited comment on MSHARED-1032 at 1/27/22, 7:40 AM:
------------------------------------------------------------------
we'll define everything step by step:
# it will be for the next version of reporting-api
[https://maven.apache.org/shared/maven-reporting-api/] (unrelated to Maven 4)
# we'll see if finally the next version of maven-reporting-api is 3.1 or 4.0
# we'll se also which exception to add: reading the javadoc, it seems that
MavenReportException looks like a better choice
[https://maven.apache.org/shared/maven-reporting-api/apidocs/index.html] ,
because reporting-api is not tied to Mojo at all (that's the role of
reporting-impl to fill the gap:
[https://maven.apache.org/shared/maven-reporting-impl/] )
on major and minor question, IMHO the important aspect is binary compatibility:
# will a new report using this modified API with an Exception still be usable
from maven-site-plugin 3.x?
# will an old report using unmodified 3.0 API without exception still be
usable from maven-site-plugin that support the new API signature?
IMHO, that will impact our choice of version both for maven-reporting-api AND
maven-site-plugin = the real user-visible impact
was (Author: hboutemy):
we'll define everything step by step:
# it will be for the next version of reporting-api
[https://maven.apache.org/shared/maven-reporting-api/] (unrelated to Maven 4)
# we'll see if finally the next version of maven-reporting-api is 3.1 or 4.0
# we'll se also which exception to add: reading the javadoc, it seems that
MavenReportException looks like a better choice
[https://maven.apache.org/shared/maven-reporting-api/apidocs/index.html] ,
because reporting-api is not tied to Mojo at all (that's the role of
reporting-impl to fill the gap:
[https://maven.apache.org/shared/maven-reporting-impl/] )
on major and minor question, IMHO the important aspect is binary compatibility:
# will a new report using this modified API with an Exception still be usable
from maven-site-plugin 3.x?
# will an old report using unmodified 3.0 API without exception still be
usable from maven-site-plugin that support the new API signature?
IMHO, that will impact our choice of version both for maven-reporting-api AND
maven-site-plugin
> API change: let canGenerateReport() throw an Exception
> ------------------------------------------------------
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
> Affects Versions: maven-reporting-api-3.0
> Reporter: Benjamin Marwell
> Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
