Add Maven informational lock file and make Maven build more replicable

[juliankuners]

In issue #4797 a problem was observed with nix packaging of Maven projects. In particular, upstream changes in Maven repositories caused the mvnHash in our derivation to be invalidated even though nothing changed in our derivation. This also breaks replicability of older derivations. This happened twice in recent times due to GSON releasing two new version of their library, as described in the respective issue #4797 from before. Maven does not support locking dependencies and transitive dependencies.

Therefore, the following potential solutions/workarounds were proposed:

• locking dependencies in a best-effort manner, potentially using the Maven plugin dependency-lock-maven-plugin
  • dependency-lock-maven-plugin does not lock dependencies for builds, but rather fails the build if the used dependencies mismatch the ones specified in a lock file, which is impractical for nix packaging
• creating a Maven mirror that does not change and contains all dependencies required for building K
• migrating to a tool such as Gradle that supports proper lock files

Migrating to Gradle causes more development effort compared to the other solutions. Locking dependencies in a best-effort way could work good enough when coupled with the lock file generating plugin dependency-lock-maven-plugin providing additional verbose information for when things break. The mirror could cause additional maintenance overhead in the future. Considering that the Java code in K is currently not being worked on, a least-effort solution seems more appropriate.

Therefore, this pull request introduces the script update-maven-locks.sh that uses dependency-lock-maven-plugin to generate lock files that are committed to the repository that can be used to determine transitive dependencies that changed version in Maven over time. The plugin is run when building the k nix derivation k-lock and lock files can be extracted from the output of the derivation. This is done automatically when running the new script update-maven-locks.sh.

Additionally, when I was locking the GSON library version, I identified that the K Maven project actually did not update the GSON version being used and that it stayed fixed due to version requirements. Instead, mvnHash changing was caused by a maven-metadata-central.xml file being included in the offline Maven repository that was generated in nix. This file includes up-to-date information of the respective Maven dependency. Excluding this file actually causes the build to break. In particular, it fails to recognize the GSON library in the Maven repository. So apparently it must be included, though I am not exactly sure why and couldn't find any documentation indicating that this file is necessary for building. I added functionality to provide these files to the Maven derivation in a reproducible manner, i.e. providing the same revision of that file instead of fetching up-to-date version from the Maven repository. This way GSON will not cause the mvnHash to break again. I only identified GSON using and depending on this file in the K repository.

[tothtamas28]

LGTM as far as I can tell. Asking for a second opinion from @jberthold.