Before this commit, an expression like `pkgs.gradle_8.override { java = pkgs.openjdk17; }` would produce a
gradle package which uses jdk 17, but has a setup hook which uses jdk 21.
Previously the regex for updating Gradle matched any major version,
resulting in version bumps like #504857 where gradle_8 was updated to
9.4.1.
After this change, the version regexp is tagged to a specific major
version. That way gradle_8 is only updated to versions that start with
'8'. At the same time version updates are enabled for gradle_9 if they
start with '9'.
Last but not least, `nix-update-script` is now called with
`--use-github-releases` because without it the updater defaults to using
GitHub's releases Atom feed, and just returns the most recent releases,
causing the gradle_8 update to fail because no matching release version
could be found.
keytool is very chatty when prompting about whether the accept the newly
generated certificate. Instead of passing a y via stdin, simply use the
-noprompt flag to indicate we're running non-interactively.
In practice, this declutters Gradle build logs.
This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
Not using the official Gradle wrapper causes papercuts like GRADLE_OPTS
and JAVA_HOME not working or misbehaving. Use the default wrapper script
and allow override of JAVA_HOME so we preserve the default Gradle wrapper
behavior.
Move the Gradle jars and bin to $out/libexec while we're at it so we
don't have to make any modifications to the wrapper ourselves
except for patching the shebang on install.
Tested with `gradle_{7,8,9}.tests` and a `nixpkgs-review rev HEAD`
to check reverse dependencies.
Fixes: #72220Fixes: #402297Fixes: #453296
Comments on #436358 and #402297 indicated a desire to have a more
controllable Gradle wrapper derivation. We were previously hiding the
Gradle being wrapped in the closure of wrapGradle, forcing us to expose
wrapGradle and use makeOverridable. Simply use callPackage to make it
easier for consumers to override things without us needing to expose gradleGen.
Currently `gradle_7.meta` does not evaluate, because evaluation is
forced in the wrapper adding the updateScript. We can move the update
script to `gradle_8-unwrapped`, for which we don't need to do this
check.
I do not think that #358845 will be finished by the
planned release date for 25.11, so let's mark is as
insecure to make it explicit that Gradle 7 is unsupported.
A passthru test of the javaToolchains configuration property was
using jdk23.
There is a requirement that the JDK version for the
test NOT be "the default for any of the gradle versions", so jdk11
is a good choice for the replacement since jdk17 and jdk21 are
currently used and jdk25 will be used in the future.
Eliminate duplicate function calls and make the API cleaner.
$ nix-instantiate --eval -A gradle.updateScript
[ <CODE> "--url=https://github.com/gradle/gradle" "--version-regex=^v(\\d+\\.\\d+(?:\\.[1-9]\\d?)?)(\\.0)?$" ]
$ nix-instantiate --eval -A gradle_7.updateScript
error: attribute 'updateScript' in selection path 'gradle_7.updateScript' not found
$ nix-instantiate --eval -A gradle_9.updateScript
error: attribute 'updateScript' in selection path 'gradle_9.updateScript' not found
Since we now have a more strict nixpkgs-vet, deal with all the Gradle
callPackage (including for unwrapped versions) in the package set,
instead of continuing to fight against CI. See #421047 for context.
Should retain complete compatibility with previous nixpkgs versions,
particularly check that there were no messups in the review.
The gradle build hook exposes an update-deps script that can,
supposedly, run without bwrap if the USE_BWRAP environment is set to 0.
Unfortunately the test on the variable was checking if it had an
non-empty value (using -n), but just above the variable is given a
default value in cases when it is empty. This meant the variable could
never be empty and therefore bwrap is always used (assuming the Nix
parameter useBwrap is true).
By changing the test into an inequality check against zero, we can
disable bwrap by setting `USE_BWRAP=0`. Any other value will leave bwrap
enabled.
Unfortunately the lack of boolean values in bash make it non-obvious
what the best representation and test for this should be. We could also
check for equality against 1 for example, or some more complicated test
that handles the string "false" as well. Using 0 as the false value
seems common place enough in scripts though.
The conversion of `useBwrap` to a string needs to be adjusted, as
`builtins.toString` actually returns an empty string for a false value.
