-
-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jreleaser-cli: init at 1.13.1 #301914
jreleaser-cli: init at 1.13.1 #301914
Conversation
I don't know much about the Java world, but, would it be possible to build from source, instead of using the JAR? |
@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. |
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.
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
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. |
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.
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. |
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 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";
};
} |
I don't want to comment further on the general approach, but regarding this bit:
This could be handled by putting the source code (sans |
I thought of that @CyberShadow but then the |
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 |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even tho I also would prefer builds from source, the reasoning for using the prebuilt binaries seems sensible / understandable.
a0eced1
to
c84332b
Compare
c84332b
to
b450e89
Compare
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
|
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 gave the mac CI two weeks, but I think she's dead :( I am not convinced waiting even longer will make it actually queue. |
Result of 1 package built:
|
@I-Al-Istannen thank you! |
Thank you! :) |
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
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.