jreleaser-cli: init at 1.13.1

[I-Al-Istannen]

Description of changes

This adds a package for the binary (jar) distribution of the https://jreleaser.org/ cli.
Source code is available, but building it requires a lot of disk space and is a bit more involved.

This is a port of the custom package used in spoon, where it is executed for each release: https://github.com/INRIA/spoon/blob/9c664544a40dd7f12e498aa44cfadb7321205fd4/flake.nix#L47-L66

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[CyberShadow]

I don't know much about the Java world, but, would it be possible to build from source, instead of using the JAR?

[I-Al-Istannen]

@CyberShadow It is possible, but as it downloads about every single JDK vendor you can think of and more during its build, I would rather avoid that. It overflows my /tmp dir and I have ~32 GiB of RAM in total… The author also said it needs some slightly peculiar versions of gradle, if I can get away with packaging their artifact (Released on GitHub, including all kinds of attestation) I would prefer that. Figuring out how exactly to bastardize their build to be nicer on resources does not sound like the best idea to me.

If it is a blocker I could spend some time, I am just not convinced it is a good idea.

[CyberShadow]

but as it downloads about every single JDK vendor you can think of and more during its build

Providing them to it using Nix / nixpkgs sounds like would fix the resource problem. It's not possible to download things inside a Nix build derivation, anyway.

The author also said it needs some slightly peculiar versions of gradle

I can't help but feel a little suspicious about that...

There's this discussion happening right now:

https://discourse.nixos.org/t/reconsider-reusing-upstream-tarballs/42524

I may be overly paranoid following recent events, but judging from its description, a tool like jreleaser looks like the perfect place to plant a backdoor, which in turn backdoors the releases it creates.

If it is a blocker I could spend some time, I am just not convinced it is a good idea.

I'm new here and not in a position to block anything, but one option on the table is to take it upstream, and kindly ask them to clean up their build, or otherwise their software will not be getting packaged.

[I-Al-Istannen]

Providing them to it using Nix / nixpkgs sounds like would fix the resource problem. It's not possible to download things inside a Nix build derivation, anyway.

Of course it is, that is what fixed-output derivations are for. The gradle build would have to be a fixed output derivation no matter what you do, nix doesn't have any other support for it as far as I can tell. The java packaging in story in nix is a bit of a disaster.

I can't help but feel a little suspicious about that...

That is pretty normal for gradle stuff, I think :P Most ship their own gradle wrapper which automatically downloads the build tools version you need.

[I-Al-Istannen]

Okay, I spent way too long on this and I don't see a faithful way to package it from source. It builds with the nixpkgs gradle (and 18 GB of disk space) well enough, but the build requires a .git folder to be deterministic (as build times and revision are based on the latest git commit). Sadly, the leaveDotGit from fetchFromGitHub or fetchgit is not reproducible, so the hash changes whenever GitHub or nix makes as a change to the .git folder.

So I would still propose packaging the final jar file.

Would be this otherwise.

{ lib, stdenv, fetchFromGitHub, makeWrapper, jre, gradle, git }:
let
  version = "1.11.0";

  jarfile = stdenv.mkDerivation {
    name = "jreleaser-jarfile";
    inherit version;

    src = fetchFromGitHub {
      owner = "jreleaser";
      repo = "jreleaser";
      rev = "v${version}";
      hash = "sha256-qsFQUZ8cui1dWIRxplhR8I79q1hW8IuINTQFroBBTS4=";
      leaveDotGit = true;
    };

    nativeBuildInputs = [ gradle git ];

    buildPhase = ''
      git config --add safe.directory $src
      gradle -Prelease=true -PreproducibleBuild=true build -S
    '';

    installPhase = ''
      cp plugins/jreleaser-tool-provider/build/libs/jreleaser-tool-provider-${version}.jar "$out"
    '';

    outputHashAlgo = "sha256";
    outputHashMode = "flat";
    outputHash = "sha256-BPJbIQnwMivec5yTy3gYu1q0NaZoQgjYynzg3cHneuM=";
  };
in
stdenv.mkDerivation rec {
  pname = "jreleaser-cli";
  inherit version;

  nativeBuildInputs = [ makeWrapper ];

  dontUnpack = true;

  installPhase = ''
    mkdir -p $out/share/java/ $out/bin/
    cp ${jarfile} $out/share/java/${pname}.jar

    makeWrapper ${jre}/bin/java $out/bin/${pname} \
      --add-flags "-jar $out/share/java/${pname}.jar"
  '';

  meta = with lib; {
    homepage = "https://jreleaser.org/";
    description = "Release projects quickly and easily";
    sourceProvenance = with sourceTypes; [ binaryBytecode ];
    license = licenses.asl20;
    maintainers = with maintainers; [ i-al-istannen ];
    mainProgram = "jreleaser-cli";
  };
}

[CyberShadow]

I don't want to comment further on the general approach, but regarding this bit:

the build requires a .git folder to be deterministic (as build times and revision are based on the latest git commit).

This could be handled by putting the source code (sans .git) into a new Git repository with just one commit. Build times are generally stripped in Nix packages, so the commit date could be set to 1970-01-01T00:00:00+0000.

[I-Al-Istannen]

I thought of that @CyberShadow but then the Revision: column in the --version output would reference a commit hash that does not exist upstream. That sounds bad to me.

[I-Al-Istannen]

After some discussion in the packaging request #303400, I believe packaging the jar file is the best approach currently.

This PR should be ready to review/merge. Quite a few Java packages only ship a jar file and I don't see a way at the moment to build jreleaser from source with the nondeterminism introduced by leaveDotGit.

[CyberShadow]

I thought of that @CyberShadow but then the Revision: column in the --version output would reference a commit hash that does not exist upstream. That sounds bad to me.

I agree. But, in my humble opinion, the better thing to do here is to simply patch out printing that line from the output (or replace it with a note that it is a nixpkgs build), rather than falling back to packaging the upstream binary.

[e1mo]

Even tho I also would prefer builds from source, the reasoning for using the prebuilt binaries seems sensible / understandable.

[chayleaf]

There's a Gradle setup hook now, so you may use that if you want. Additionally, for .git, you can try something like this

nixpkgs/pkgs/by-name/pk/pkl/package.nix

Lines 17 to 27 in 0770242

	leaveDotGit = true;
	postFetch = ''
	cd "$out"
	export commit_id=$(git rev-parse --short HEAD)
	cp ${./set_commit_id.patch} set_commit_id.patch
	chmod +w set_commit_id.patch
	substituteAllInPlace set_commit_id.patch
	git apply set_commit_id.patch
	rm set_commit_id.patch
	find "$out" -name .git -print0 | xargs -0 rm -rf
	'';

[I-Al-Istannen]

I am not sure that hook helps here, as e.g. tests download gigabytes of random JDKs to test against as well. I also tried packaging it from source again (for an hour or two) by patching the gradle build, but it is still not reproducible. I would prefer staying with the release jar for the time being.

[I-Al-Istannen]

I gave the mac CI two weeks, but I think she's dead :( I am not convinced waiting even longer will make it actually queue.

[onny]

Result of nixpkgs-review pr 301914 run on x86_64-linux 1

1 package built:

• jreleaser-cli

[onny]

@I-Al-Istannen thank you!

[I-Al-Istannen]

Thank you! :)