improvement proposed: review appreciated https://github.com/apache/maven-reporting-impl/pull/24
Le mercredi 4 octobre 2023, 08:30:04 CEST Hervé Boutemy a écrit : > Hi Xander, > > Sorry, I lost track, having a look now. > > When I see that you are implementing Mojo's "execute()" [1] while using > maven-reporting-impl, you are in fact defeating the objective of > maven-reporting-impl: do that for you. > > maven-reporting-impl would probably need better documentation, I need help, > but the IT [2] tries to show how to write such reporting code that can be > run both as goal and a maven-site's report > > And if you want to see how it does the job, you can look at > maven-reporting-impl AbstractMavenReport implementation of execute() [3]: > yes, that implementation changed, and now I remember I had to update it > because of the NPE that it could cause. You must not rewrite this code. > > HTH > > Hervé > > > [1] > https://github.com/dev-aspectj/aspectj-maven-plugin/blob/main/src/main/java > /org/codehaus/mojo/aspectj/AjcReportMojo.java#L210 > > [2] > https://github.com/apache/maven-reporting-impl/tree/master/src/it/setup-rep > orting-plugin/src/main/java/org/apache/maven/reporting/its/custom > > [3] > https://github.com/apache/maven-reporting-impl/blob/master/src/main/java/or > g/apache/maven/reporting/AbstractMavenReport.java#L187 > Le mercredi 4 octobre 2023, 04:05:58 CEST Alexander Kriegisch a écrit : > > Hello Hervé. > > > > Did the reproducer help you in any way? > > > > Regards > > > > > Hello Hervé. > > > > > >>> I tried to upgrade those > > >>> dependencies to the most recent Doxia and Sitetools versions. > > >> > > >> by "most recent", do you mean most recent from 1.x or 2.0.0-M*? > > > > > > I mean 2.0.0-M*. Actually, the project works nicely and I would have > > > ignored the Dependabot suggestions, but all those Maven warnings about > > > outdated or EOL components made me start upgrading them. I was under the > > > impression that Doxia milestones are just as stable and production-ready > > > as Surefire ones, so I did not think much and gaven them a go. > > > > > >> 1.x should not cause issues > > >> > > >> 2.0.0-M*, as expected from the version number, is more risky and not > > >> yet > > >> fully > > >> > > >> stable > > > > > > Then maybe it is better to revert to 1.x and let users live live with > > > the > > > Plexus warnings for a little longer. > > > > > >> Such reporting plugin coding has so many ways to be done that sharing a > > >> reproducer is the easiest way to have concrete view on what is > > >> happening, > > >> particularly if you're going to 2.0.0-M* > > > > > > Sure, it is about https://github.com/dev-aspectj/aspectj-maven-plugin. > > > > > > On the main branch, > > > > > > -- an older commit like 93110452 shows the (stable) situation before I > > > > > > started various and sundry plugins and dependencies, > > > > > > -- second-latest commit 7b8706a7 - see also build > > > > > > https://github.com/dev-aspectj/aspectj-maven-plugin/actions/runs/62 > > > 30 > > > 950536 > > > - shows an intermediate step in which the plugin's reporting > > > goalfails in integration tests, > > > > > > -- latest commit 1a819a4e stabilises the integration tests, but is a > > > > > > hacky work-in-progress commit that needs to be cleaned up. You > > > asked for a reproducer, so I pushed the commit. > > > > > > You can build the plugin quickly, if you deactivate the > > > 'integration-test' profile. In order to reproduce the problem, run > > > something like > > > > > > mvn -Dinvoker.test=CreateReport verify -P integration-test > > > > > > on the lat6est commit, but locally revert this change in > > > AjcReportMojo.java: > > > https://github.com/dev-aspectj/aspectj-maven-plugin/commit/1a819a4e0b2c3 > > > c > > > d34797c3122488ea5833cf9fd5#diff-64f2431d9507f2996b65ccf8f9a4e202923d456e > > > 31 > > > 579f3809ef4d648509b62e > > > > > > Regards > > > -- > > > Xander > > > https://scrum-master.de > > > > > >> Le jeudi 7 septembre 2023, 04:35:29 CEST Alexander Kriegisch a écrit : > > >>> Hello Maven community. > > >>> > > >>> In a Maven plugin using old 1.x Doxia and Sitetool versions, I am > > >>> getting > > >>> warnings because those again use an EOL Plexus component. The details > > >>> are > > >>> not so important, the important part is that I tried to upgrade those > > >>> dependencies to the most recent Doxia and Sitetools versions. > > >>> > > >>> One class in the plugin extends > > >>> org.apache.maven.reporting.AbstractMavenReport. It implements an > > >>> executeReport(Locale) method, which so far was fine. But now, it also > > >>> inherits execute() from the abstract parent class. The latter method > > >>> is > > >>> always called when using the reporting goal for my plugin. The result > > >>> is > > >>> an > > >>> > > >>> error like this: > > >>> Caused by: java.lang.NullPointerException: Cannot invoke > > >>> > > >>> "org.apache.maven.doxia.tools.SiteTool.getSiteLocales(String)" because > > >>> "this.siteTool" is null at > > >>> org.apache.maven.reporting.AbstractMavenReport.getLocale > > >>> (AbstractMavenReport.java:400) at > > >>> org.apache.maven.reporting.AbstractMavenReport.reportToMarkup > > >>> (AbstractMavenReport.java:212) at > > >>> org.apache.maven.reporting.AbstractMavenReport.execute > > >>> (AbstractMavenReport.java:189) > > >>> > > >>> I see that AbstractMavenReport defines the 'siteTool' field as follows: > > >>> @Component > > >>> protected SiteTool siteTool; > > >>> > > >>> I am wondering why that field is null. Should it not be populated > > >>> automatically by dependency injection? I have a dirty workaround for > > >>> this > > >>> > > >>> problem: > > >>> @Override > > >>> public void execute() throws MojoExecutionException { > > >>> > > >>> //super.execute(); > > >>> try { > > >>> > > >>> executeReport(Locale.getDefault()); > > >>> > > >>> } > > >>> catch (MavenReportException e) { > > >>> > > >>> throw new MojoExecutionException(e); > > >>> > > >>> } > > >>> > > >>> } > > >>> > > >>> This way, 'siteTool' is not used and method > > >>> SiteTool.getSiteLocales(String) > > >>> never called. But I guess, that is not a good solution to the problem. > > >>> How > > >>> are plugin implementors meant to deal with this situation? Or is this > > >>> some > > >>> kind of bug? I am unsure how to proceed. I am by no means a Maven > > >>> plugin > > >>> buff and merely helping to keep an existing plugin alive. I would be > > >>> grateful for hints. > > >>> > > >>> Regards > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
