Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null
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-reporting-plugin/src/main/java/org/apache/maven/reporting/its/custom [3] https://github.com/apache/maven-reporting-impl/blob/master/src/main/java/org/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/6230 > > 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/1a819a4e0b2c3c > > d34797c3122488ea5833cf9fd5#diff-64f2431d9507f2996b65ccf8f9a4e202923d456e31 > > 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 AbstractMav
Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null
Hello Hervé.
Did the reproducer help you in any way?
Regards
--
Alexander Kriegisch
https://scrum-master.de
Alexander Kriegisch schrieb am 23.09.2023 10:00 (GMT +07:00):
> 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/6230950536
> - 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/1a819a4e0b2c3cd34797c3122488ea5833cf9fd5#diff-64f2431d9507f2996b65ccf8f9a4e202923d456e31579f3809ef4d648509b62e
>
> 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.
Re: "First time caller..." javadoc taglet dependencies?
Hi Joseph. I think you uncovered a bug in Maven Javadoc Plugin. I just created https://issues.apache.org/jira/browse/MJAVADOC-775 on your behalf. As a workaround for the non-functioning 'tagletpath' option, I recommend to separately publish the taglet library as a Maven artifact, which then you can refer to using the 'tagletArtifact' option. The hypothetical workaround to just use a system-scoped dependency and refer to that in 'tagletArtifact', is not working either. So, until this will have been fixed, your options are very limited. Because I was looking at the two simple taglet classes in your JAR anyway from my IDE when analysing your problem, in the attached ZIP archive is the decompiled source code for both classes, just in case you do not have the sources anymore and want to recreate the JAR as a separate artifact. I hope that the mailing list does not strip off attachments. Regards -- Alexander Kriegisch https://scrum-master.de Joseph Kessselman schrieb am 04.10.2023 05:41 (GMT +07:00): > Hi, folks. I'm in the process of trying to port the Apache Xalan build > from Ant to Maven. It's close to usable, but I'm still struggling with a > few odd corners. > > One of the odder corners: The Xalan documentation uses a javadoc taglet, > @xsl.usage, to indicate whether a method is intended only for internal > use despite having to be public for cross-package references. This is > working fine in one of the two modules of this project, but in the other > I get: > > [ERROR] javadoc: error - Error - Exception > java.lang.ClassNotFoundException thrown while trying to register Taglet > xalan2jtaglet.XSLUsageTag... > [ERROR] > /home/keshlam/git/xalan-java-mvn/serializer/src/main/java/org/apache/xml/serializer/AttributesImplSerializer.java:37: > > error: unknown tag: xsl.usage > > Not a very helpful error message Trying to probe at this, the best > guess I have is that the taglet code has a dependency on another > jarfile, specifically tools.jar (or equivalent). None of my POMs > explicitly reference tools.jar, but it's possible that one module is > acquiring it as an indirect dependency while the other isn't. > > My question is whether this diagnosis is likely to be vaguely correct, > if not how to get a more useful error message out of the javadoc > invocation, and if so how to make tools.jar available to the taglet in a > moderately portable manner. I've been trying various fragments from > Stack Overflow and haven't found one that worked for me yet, hence the > question here. > > > > The overall porting attempt is checked in as > https://github.com/jkesselm/xalan-java-mvn.git if you want to look at > the configuration as it currently stands, with this problem as yet unsolved. > > Thanks in advance. "If it was easy, they wouldn't need _us_." > > > (If anyone is foolish enough to want to glance over the pom.xml files > for this build and sanity-check them for massive volations of Maven > idiom or horrible misunderstandings of Maven use, I'd greatly appreciate > it. I haven't previously written a Maven configuration and a lot of this > has been guesswork based on how many other build systems have behaved.) > > - > 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
"First time caller..." javadoc taglet dependencies?
Hi, folks. I'm in the process of trying to port the Apache Xalan build from Ant to Maven. It's close to usable, but I'm still struggling with a few odd corners. One of the odder corners: The Xalan documentation uses a javadoc taglet, @xsl.usage, to indicate whether a method is intended only for internal use despite having to be public for cross-package references. This is working fine in one of the two modules of this project, but in the other I get: [ERROR] javadoc: error - Error - Exception java.lang.ClassNotFoundException thrown while trying to register Taglet xalan2jtaglet.XSLUsageTag... [ERROR] /home/keshlam/git/xalan-java-mvn/serializer/src/main/java/org/apache/xml/serializer/AttributesImplSerializer.java:37: error: unknown tag: xsl.usage Not a very helpful error message Trying to probe at this, the best guess I have is that the taglet code has a dependency on another jarfile, specifically tools.jar (or equivalent). None of my POMs explicitly reference tools.jar, but it's possible that one module is acquiring it as an indirect dependency while the other isn't. My question is whether this diagnosis is likely to be vaguely correct, if not how to get a more useful error message out of the javadoc invocation, and if so how to make tools.jar available to the taglet in a moderately portable manner. I've been trying various fragments from Stack Overflow and haven't found one that worked for me yet, hence the question here. The overall porting attempt is checked in as https://github.com/jkesselm/xalan-java-mvn.git if you want to look at the configuration as it currently stands, with this problem as yet unsolved. Thanks in advance. "If it was easy, they wouldn't need _us_." (If anyone is foolish enough to want to glance over the pom.xml files for this build and sanity-check them for massive volations of Maven idiom or horrible misunderstandings of Maven use, I'd greatly appreciate it. I haven't previously written a Maven configuration and a lot of this has been guesswork based on how many other build systems have behaved.) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-javadoc-plugin cannot find symbol in another module while building a multi-module project
Hello,
I am compiling a multi-module project with Maven. When I run maven clean
install the compilation succeeds on a submodule but the javadoc plugin
throws error while trying to generate javadoc for the submodule that has
dependency on another submodule. My parent pom has:
org.apache.maven.plugins
maven-javadoc-plugin
3.5.0
none
true
false
none
20
attach-javadocs
jar
I get an error that looks like:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (attach-javadocs)
on project yyy-core: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1
[ERROR] /Users/xxx/code/yyy/core/src/main/java/yyy/impl/v1/zzz.java:6:
error: cannot find symbol
[ERROR] public static aaa create() {
[ERROR] ^
[ERROR] symbol: class aaa
[ERROR] location: class zzz
[ERROR] /Users/xxx/code/yyy/core/src/main/java/yyy/impl/v1/zzz.java:3:
error: package yyy.core.api does not exist
[ERROR] import yyy.core.api.*;
What am I doing wrong here and how can I fix it? Thanks.
S.
