Introduce buildMaven derivation

[fzakaria]

Simplify the process of building a runnable JAR by including a useful derivation for others to use.

It requires that the project under question is setup specifically to use the repositoryLayout however if so; it makes on-boarding onto mvn2nix super easy.

{ pkgs ? import <nixpkgs> {} }:
let
  mvn2nix = import
    (fetchTarball "https://github.com/fzakaria/mvn2nix/archive/master.tar.gz")
    { };
  buildMavenRepository = mvn2nix.buildMavenRepository;
  buildMaven = mvn2nix.buildMaven;
  mavenRepository =
    buildMavenRepository { generated = import ./dependencies.nix; };
in buildMaven {
  jdk = pkgs.jdk11_headless;
  generated = import ./dependencies.nix;
  repository = mavenRepository;
  # we set the source directory one level higher
  # this is just for this example
  src = ../../.;
}

At the moment, I've decided to only include buildMaven to create a runnable JAR artifact since that seems the most likely usage for someone wanting to bring their Maven application into a Nix derivation.

We can consider alternative derivations that simply generate a JAR.

[fzakaria]

@DerGuteMoritz curious for your thoughts.

[fzakaria]

Might make sense to split this:
buildMavenJar & buildMavenExecutable or something and have buildMavenExecutable create a linkFarm of the repository & output of buildMavenJar

[fzakaria]

@roberth also since you have good insights :)

[fzakaria]

An unfortunate way mvn2nix operates now is that the test dependencies are part of the runtime closure because the full maven repository is included.

Not sure a great solution here without restarting that whole problem about using aether etc..

[roberth]

You could figure out some rudimentary scope info by invoking maven more than once. For example

1. mvn -Dmaven.test.skip=true
2. scan the temporary maven repo
3. mvn
4. scan again

The difference between the scans will tell you something about test dependencies. My example won't help you distinguish between plugin dependencies and build dependencies though, but there's probably something you can do with the goals to tease out more information about that.
It won't be perfect, but it might be a safe optimization in most cases.

You could also use the pom and aether for determining runtime dependencies but still use repo scanning to figure out plugin dependencies on top of that.

Ultimately this is also a problem for the project author to solve. They probably haven't been shipping entire repos or sources only. Most projects will build an assembly or fat jar or something, so they should have an installPhase that only copies the distributable files.