NullPointerException during create-runtime-image

[ekpeters]

NullPointerException during create-runtime-image

[ekpeters]

(Apparently there are issues pasting xml into the editor here... what the issue system is showing most of the pom, and my attempts to fix it did not improve it any - though making it worse turns out to be trivial - if there's a magic trick to remedy that, I don't know it)

[aalmiray]

@ekpeters When you say "Works fine in release 1.0.0.RC1", what does that mean?
a) the plugin creates a runtime image that includes the JAR
b) the plugin creates a runtime image that DOES NOT include the JAR
c) the plugin does not create an image and fails silently
d) something else

Because as far as I can tell:
a) this should not have happened unless the JAR exists somehow and it's found by the plugin using regular filesystem APIs instead of expecting the artifact to be attached to the current Maven session, which is what I suspect is happening in later versions and should happen.
b) if the JAR is read from the attached artifact set (expectation) and its not found then the runtime would not contain it. Possible but unlikely as that would break the original goal of the invoked mojo.
c) if so, that's a bug. the fact that there's an error (even an NPE) is better.

[bmarwell]

Can you try just using moduleInfoSource, please?

[ekpeters]

That was a while back, my memory's a bit fuzzy, but that I recall it was one headache on top of another... the whole 'one step forward three steps back' nonsense.

Looking at the state of things and what was done...

Old:
A single maven project performing the following tasks.

• Collects all dependencies into target/libs (maven-dependeny-plugin - copy-dependencies)
• Copies modular jars from target/libs into target/modules. (maven-resources-plugin - copy-resources)
• uses Moditect to modularize jars in target/libs that are not already modular, or to apply corrections to the odd defective module-info (because not everyone making modular jars knows how to make correct modular jars), output going to target/modules. This is done exclusively using moduleInfoFile to specify each module in full.
• Do other work (cut DLLs from some jars - we don't need 2 copies of DLLs, and some are big).
• create a jlink image with the resources in target/modules
• More work (pack cut DLLs into the created image).
• Pack the image into a zip file.
• Push the resulting zip file (and not any jars - those can/do confuse support) to the maven repo.

This blows up on RC2 with a NPE...
CreateRuntimeImageMojo.java:129

New:
One maven project (packaging: jar) that does all the above work, but has all install/deploy tasks suppressed. Hard coded to Moditect 1.0.0.RC1 (overrides dependency management)
Then a second project (packaging: pom) that reaches into ../prepare/target to deploy the resulting zip archive to the maven repo (because moditect won't do the work under pom packaging - but that's unrelated to this issue...)

---

Dunno... could that shuffling of jars around be what mucks things up - ultimately we have one set of jars pulled in with the dependency plugin, and then Moditect is making updated copies of the same jars, in a different folder, which ultimately is the folder we use for the jlink image...

[aalmiray]

The create-runtime-image is bound by default to the package lifecycle phase. You have explicitly rebound the goal to generate-resources which runs much earlier and the project's artifact is not yet ready. The NPE occurs at

moditect/maven-plugin/src/main/java/org/moditect/mavenplugin/image/CreateRuntimeImageMojo.java

Line 126 in 5d63f7b

project.getArtifact().getFile().toPath(),

ModiTect is failing as it should as the expectation is to create a runtime image with the project's artifact as an input.

[bmarwell]

@aalmiray I can create a PR with a nicer error message, if that is acceptable to you all?

[ekpeters]

(and I'm coming back late to the conversation late... meh)
From my perspective, the artifact is a zip file, as that's what is pushed to the maven repo... I realize maven has it's own ideas on the matter, but there's no source to compile, no jar, ear, or war to assemble - Instead of those, it's a zip file, consuming the output of 20-odd projects and ~20 or so 3rd party jars

[github-actions]

🎉 This issue has been resolved in 1.2.0.Final (Release Notes)