As someone who uses Gradle daily at work and for personal projects, I found existing solutions to package Gradle applications in Nix lacking. I tried gradle2nix, but I don’t like the approach of generating Nix expressions. It’s also quite complex, as it deals with all sorts of Gradle internal edge cases – most of which probably don’t matter to me.
Inspired by nix-npm-buildpackage, I created buildGradleApplication to simplify the integration of Gradle projects into the Nix ecosystem. It defines a set of rules and constraints that a Gradle project must follow. These rules/constraints are mostly Gradle best practices anyway, so it should be relatively easy to adopt - at least for moderately complex builds.
This approach has worked well for me in various projects so far - and I hope it can help you too.
If you working with Gradle, I encourage you to try it out and provide feedback. If you encounter any issues or have questions, let me know! You can open an issue, create a pull request, or send me an email.
Thank you to @infinisil, Fabian and Alain for your feedback!
I wonder if it could be merged into nixpkgs. I understand that this is not supposed to work on all projects, but right now we have no standard gradle builder, so this could still be a win.
Exactly, it’s not supposed to work on all projects - and it probably won’t work with any gradle project currently present in nixpkgs without upstream modifications. For packaging upstream packages, a MITM-Approach is probably the solution that works most reliably.
If I understand it correctly, it’s also not an option to merge it as is into nixpkgs because it uses a derivation internally to read the dependencies from the gradle/verification-metadata.xml (since nix cannot read XML files as far as I know) - which is not allowed as it would take too long to evaluate.
Yes, IFD is not allowed in Nixpkgs (for good reason).
You could however explore an alternative approach that buildNpmPackage et. al. also use where all dependencies are fetched in a single vendor FOD (cargoHash, npmDepsHash etc.). This works as long as every dep is locked upstream, artefacts don’t change in the repos and the output format is reproducible.
This would also make it distinct from gradle2nix’ approach which (like most 2nix tools) generates a lockfile to be checked into VCS which has proven itself to be quite costly w.r.t. repository size.
