mvnix generates incorrect repo entry for local repos

[ToxicFrog]

I'm trying to package Airsonic. Airsonic includes in its repo jars for specific versions of various dependencies, and a pom.xml that points at them. Mavenix, however, rather than generating a pointer to the source checkout at nix-build time, instead points at wherever the source tree was when you ran mvnix-update:

$ git clone https://github.com/airsonic/airsonic.git
$ cd airsonic
$ git checkout v10.5.0
$ mvnix-init
$ nano default.nix
    # Necessary because the CVE checker relies on runtime fetches of dependencies which
    # don't work on Nix.
    MAVEN_OPTS = "-Ddependency-check.skip=true";
$ mvnix-update default.nix
$ cat default.nix
  ...
  "remotes": {
    "4thline-repo": "http://4thline.org/m2",
    "central": "https://repo.maven.apache.org/maven2",
    "jaudiotagger-repository": "https://dl.bintray.com/ijabz/maven",
    "local1": "file:///home/toxicfrog/src/airsonic/airsonic-main/../repo"
  },
  ...

If you use mvnix-init -S 'fetchGit ...' instead, it gives you a path in /run/user/ instead.

The former works fine for local builds (the latter stops working as soon as you reboot or the temp directory created by mavenix gets otherwise cleaned up), but isn't great for packaging. I believe I can work around this by making a separate package that only contains those jars, derived from the same source, and then pointing mavenix.lock at that, but this seems like something mavenix should be able to handle on its own.

[icetan]

Hi,

haven't noticed this before, I'm just grabbing whatever remotes maven spits out.

Good catch!

Will see if I can translate local paths to nix paths maybe.

[ToxicFrog]

In the meantime I did eventually figure out a workaround that is, I think, minimally gross:

mavenix.buildMaven rec {
  src = fetchGit { ... };  # or wherever your src comes from
  remotes = { local1 = "file://${src}/repo"; };  # replace local1 and the repo/ subpath as needed
  # ...
}