[core] Add a distribution type for single executables

[aalmiray]

Discussed in #1073

^{Originally posted by aalmiray November 29, 2022}
A few days ago I stumbled upon https://github.com/CycloneDX/cyclonedx-cli/ and noticed their build could be released with JReleaser. Forked the project at https://github.com/aalmiray/cyclonedx-cli/ and made the necessary adjustments. To my delight I was able to post an early-access release of my own with all artifacts https://github.com/aalmiray/cyclonedx-cli/releases/tag/early-access 🚀

Now, I noticed that the CycloneDX organization has a Homebrew tap (https://github.com/CycloneDX/homebrew-cyclonedx) that allows matching binaries posted by https://github.com/CycloneDX/cyclonedx-cli/ to be installed via Homebrew. Unfortunately the release settings I put in place on my fork do not allow Homebrew to be used because all artifacts are posted via the files: section instead of distributions:.

A bit more of context. files: are used to list a set of artifacts that may be added as release assets but they do not participate in anyway with settings defined in packagers:. OTOH distributions: define a set of artifacts that follow certain conventions and characteristics, making them easier to be processed by packagers:.

There's a BINARY distribution that could be used in this case as_long_as binaries are packaged into a Zip file with an specific file structure (see https://jreleaser.org/guide/latest/distributions/binary.html). I don't think I'll ever convince CycloneDX to change their release assets. Likely others won't see a reason to zip a binary if the only file they want to release is the binary itself (no license, readme, config, additional files needed).

Thus, I think it may be a good idea to support a new kind of distribution (similar to BINARY) but its artifacts do not have to be packaged inside an archive (zip or tar). This new distribution could be named FLAT_BINARY, SINGLE_BINARY or something else. Making it a proper distribution would signal packagers that they may process its artifacts. Of course new templates would have to be added as BINARY expects zips or tars and packagers react to those file types accordingly.

cc: @sormuras @helpermethod

[coderpatros]

@aalmiray heya, I'm the maintainer of the CycloneDX CLI tool. Feel free to open an issue to discuss changing the release artefact structure and why.

[aalmiray]

Hi @coderpatros! Thank you for chiming in. The reason for preferring an archive over a single binary is for delivering additional files such as a license, readme, and so forth. Package managers can deal with archives or the plain binary, in that regard CycloneDX is good to go as it is today.

Consumers of cyclondx-cli are used to downloading the binary as is. Wrapping it with an archive would change the way they interact with the project.

In order to keep what cyclonedx-cli offers today JReleaser is prepared to support binaries without archives. The feature is almost complete and will be ready for 1.4.0. The release comes out by Dec 30th. If you want we could explore how JReleaser may support cyclonedx with its current release options. Later, if archives were to be the chosen option going forward then we could effortlessly adapt the release process once again.

I'll follow up with an issue at the cyclonedx-cli repo as suggested.

[aalmiray]

Released in v1.4.0 -> https://github.com/jreleaser/jreleaser/releases/tag/v1.4.0