Move native image to its own profile

[aalmiray]

Building a Native Image is a time consuming operation. The current setup has it active in the main lifecycle which means native executables are generated every single time mvn package or mvn verify are issued. It would be better to move native image configuration to its own profile.

WARNING: This move likely affects release configuration.

[bdemers]

It's funny you mention that!
Digging into JReleaser has been on my TODO list for a while, which hopefully can help a lot with dealing with the release config (as well as automate the current manual steps when deploying to Homebrew and Chocoletey)

That said, building the native image in the main lifecycle was intentional. GraalVM is great, but there have been a lot of gotchas, and testing the native image build was the only way to find the problems. The binary dist is also what we are "shipping", which adds to the testing emphasis.

I'm not saying we shouldn't do this! Especially if anyone is consuming the CLI as a JAR (it may help speed up test cycles for those folks)

[aalmiray]

Right. I've got a branch in my fork with initial JReleaser configuration. It can package all 3 native images as zips and publish to a git release. The next step would be to configure a Homebrew cask, a Chocolatey build, and ... maybe add Flatpack support to JReleaser as it currently does not generate a manifest based on existing project metadata.

This being said, moving the NI to its own profile can still be tested: explicitly by a developer by enabling the matching profile and/or on CI where the profile is always enabled. JReleaser could publish early access releases on every push to main ;-)

[aalmiray]

FWIW moving the Native Image to its own profile could be done like this https://github.com/gunnarmorling/kcctl/blob/9598e8c9de05f7aed79aa943752e5b4c7818f0f9/pom.xml