ack, @yegortimoshenko I merged a different clojure PR! Would you like to rebase this against master?

Oh well, no one between #32527, #32700 and this PR wants to build Clojure from source.

@orivej I'll do that!

@orivej Done, check it out. It does not build actual Clojure from source, because it's only a dependency of clojure-tools (which is what is packaged here), but it does build clojure-tools from source.

Even if we do build Clojure from source, new tooling fetches all project dependencies from Maven at runtime, which includes Clojure.

@grahamc Rebased!

That's dismaying, I'll see if I can fix it.

clj does not work when rlwrap is not available in PATH and #32527 has fixed that, but I don't mind if we don't because the error message is clear (“Please install rlwrap for command editing or use "clojure" instead.”), the dependency is optional and it introduces dependencies absent from the clojure closure (readline and ncurses).

I also ended up concluding that the existing maven support in nix wasn't quite ready for primetime, and that mvn dependency:go-offline was incomplete. So I took a similar approach of first running the build outside of nix and then capturing the state of the local repo. However in my approach that bootstrapping build is done once outside of the nix expression and produces a declarative description of what's needed. See #19741 (comment) and following for details.

@jerith666 I think it'd be very burdensome to maintain.

Fixing double build isn't very important as Java projects build fast. Could be fixed by replacing project files with some dummies so that plugins would trigger and package a fake jar (package presumably being the only phase we're interested in).

I'm not sure it's any more burdensome. In both cases, if any dependency changes, you have to re-run the build outside of nix and capture a new blob of data about the new dependencies -- in your approach, a combined checksum, in mine an exploded-out list of checksums. But either way you just drop in the new generated thing and move on.

If you have a bunch of maven builds, though, my approach lets you share all their shared dependencies in the nix store.

I'm not sure it's any more burdensome. In both cases, if any dependency changes, you have to re-run the build outside of nix [...]

One can just invalidate fetchMaven sha256, and run nix-build. It will try to fetch (and currently, build), then it will show the new checksum. No need to do anything outside of Nix.

If you have a bunch of maven builds, though, my approach lets you share all their shared dependencies in the nix store.

Most dependencies end up in uberjars. Also, Nix can dedupe these jars via nix-store --optimize if necessary, but yes, it will re-fetch same jars for every package.

Reimplementing native Maven fetcher is a bad idea: your fetcher won't handle classifiers, Maven repositories other than Central, exclusions, custom destFileName or outputDirectory, stripVersion flag, and probably a whole bunch of other corner cases I couldn't come up with right away: https://maven.apache.org/plugins/maven-dependency-plugin/usage.html

@orivej

clj does not work when rlwrap is not available in PATH and #32527 has fixed that, but I don't mind if we don't because the error message is clear (“Please install rlwrap for command editing or use "clojure" instead.”), the dependency is optional and it introduces dependencies absent from the clojure closure (readline and ncurses).

What if we move clj to a separate derivation (or output)?