Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Alexander Kriegisch]

Hello.

I was asking this question two weeks ago. Can somebody tell me if maybe I asked 
on the wrong list or in the wrong way and possible direct me elsewhere?

Thank you all. Best regards
--
Alexander Kriegisch
https://scrum-master.de


Alexander Kriegisch schrieb am 07.09.2023 09:35 (GMT +07:00):

> 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

maven-build-cache, immutable docker tags, etc

[Ben Tatham]

Hi,
I'm loving the ideas in the maven-build-cache, but I'm running into some
circular build issues that are blocking us from using it at the moment.

In many of our projects, we deploy docker images. Ideally, we would like to
keep our docker images immutable. To achieve that, we have extra maven
plugins that create unique SNAPSHOT version numbers (based on jira issue
ids, git commit hashes, and/our CI build numbers).  We do this for docker
image immutability, but also to avoid SNAPSHOT collisions when multiple
developers are working at the same time in the same project, but still be
able to deploy the snapshot artifacts for other reasons (temporary test
deployments, sharing libraries as snapshots while still in development
across projects, etc).

But that solution creates unique maven versions in CI for every build,
which of course then contradicts using maven-build-cache, since the version
is always different in CI.

To use maven-build-cache, we would just go back to using standard -SNAPSHOT
builds, but then we have to solve our original issues a different way.

(Sadly, AWS ECR only allows setting immutability at the registry level. I
looked at nexus as a docker registry, and it seems to be even higher at the
whole docker repo level. (We wish we could set immutability of images based
on the tag - ie allow -SNAPSHOT tags to mutable, but nothing else))

One idea we have is to use a different docker registry for snapshot vs
release builds, but since maven properties are evaluated at the beginning
of the maven lifecycle, we cannot change the parameters sent to maven
plugins that due to the docker builds once the build starts. Thus, we would
have to do something outside of maven to detect, eg, if the build is a
snapshot and choose a different docker registry there and pass it on the
command line. We would love this to be an all-maven solution.

Does anyone else run into similar issues with maven-build-cache?  Is there
some weird way we can ignore the project.version altogether on the
maven-build-cache (that seems very odd, for sure though)?  Other ideas?

Thanks,

Ben

[image: -] 
[image: -]  [image: -]

[image:
-] 

Ben Tatham
Principal Software Developer
Nanometrics
bentat...@nanometrics.ca

-- 
This message is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
proprietary, privileged, confidential or otherwise legally exempt from 
disclosure. If you are not the named addressee, or have been inadvertently 
and erroneously referenced in the address line, you are not authorized to 
read, print, retain, copy or disseminate this message or any part of it. If 
you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies of the message.