Updating `jugglinglab`, packaging a Maven repository

Development
1

I am trying to update jugglinglab, see jugglinglab: 1.2.1 -> 1.4.1 [WIP] by dschrempf · Pull Request #120757 · NixOS/nixpkgs · GitHub.

It turns out, that a new dependency Google Ortools is blocking the update. Ortools is available for Python in Nixpkgs, but not for Java. When I try to add the java build, I am running into quite a lot of trouble because the build is based on two Maven projects, both accessing a lot of external dependencies.

What are current best practices to build Maven based project in Nix? I had a look at Packaging a Maven application with Nix | Farid Zakaria’s Blog and subsequently at GitHub - fzakaria/mvn2nix: Easily package your Maven Java application with the Nix package manager..

However, the Maven projects have wrong (too high) minor version numbers. This is unnoticed when using Maven alone, it just pulls the latest available version. However, when executing mvn2nix, I get the following error:

java.lang.RuntimeException: Could not find artifact com.google.ortools:ortools-linux-x86-64:pom:9.0.9999 in any repository

(The corrent version number is 9048). I could now use a patch to replace the wrong version numbers but that feels wrong. What do you suggest?

Further, the generated dependency file has 2479 lines. Is it encouraged to add such files to Nixpkgs? Any update to this package requires regenerating this file, which is quite resource intense. Any ideas about how to streamline the process? Sometimes Nix packaging is a little frustrating … :).

Thanks,
Dominik

2

I can chat about this on #jvm on matrix sometime about ideas or how to proceed for more thorough derivations.

The easiest if this is your personal nixpkgs is to disable sandboxing if your sandbox mode is set to “relaxed”.

Kind of a cop-out but for really complicated maven builds gets you what you want.

3

There’s quite a lot of subtle problems with Maven and Java at a fundamental level that make using it in a fixedOutput style annoying :slight_smile: