[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

maven build system - new insights

From: Hartmut Goebel
Subject: maven build system - new insights
Date: Thu, 31 Jan 2019 11:00:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

H Julien,

as promised I've spend some time on a maven build system (as always when regarding maven it was much more time than expected). I did not yet create a build-system but want to share my insights so we can decide how to proceed further. If I'm wrong on some points, please feel free to correct this. Everything below is based on my investigations the last days.

TL;DR: Let's use XMvn [11] for our maven build-system. What do you think?

  • The only place where maven actually loads artifacts from is the local repository, which is a single directory (default: $HOME/.m2/repository). If an artifact is not found in the local repository, it is downloaded from some "remote" repositories and cached in the local repository. I have not found any way to change this behavior. See Analysis of repositories behavior below for details.
  • The local repository path can be changed by passing "-Dmaven.repo.local=..." to maven.
  • The files in the repository need to be structured like this:
    • .../org/apache/maven/maven-plugin-descriptor/2.2.1/maven-plugin-descriptor-2.2.1.jar

This implies a maven-build-system would need either to merge all artifacts into a "local repository" or to set up a lot of "mirrors" (one for each input, this will copy all artifacts into the "local repository"). Both is complicated.

Thus I suggest to leverage Xmvn [11] for building (see Distro-Analysis below for details). Xmvn searches for configurations (and thus repository definitions) in e.g $XDG_DATA_DIRS plus it requires only ca. 32 jar-files (compared to ca. 48 for maven). Thus we could not only solve the repository issue but also (hopefully) reduce the number of packages we need to bootstrap.


Here is what other GNU/Linux distributions do:

  • Debian stores the files in a system repository structured like above, see [9]. (Thought this seem not to be done for all packages, e.g.[6] and [7] do not include these maven-repo files.)
  • Debian provides a script "mvn-debian" [8] which seem to tweak maven to use this system repository (by passing -Dmaven.repo.local=$MAVEN_REPO").
    • This is still a single directory. For guix this would require all inputs to be merged into a single directory :-(
  • Debian also has some build-helper "mh_make" [10] which does some more magic I did not investigate by running some Debian-specific java classes for collecting dependencies.
  • Fedora uses xmvn [11] which "extends" maven to maintain a system-wide repository of artifacts.
  • There is also a "Dependency-reduced version of XMvn" [12], incapable of using remote repositories. This could be helpful for bootstrapping.
    • A sort analysis says: 32 instead of 48 jar-files are required. Thus we might be able to eliminate 1/3 of the dependence for bootstrapping maven.
  • The directory structure does not follow the repo-structure, but lloks like this:
    • /usr/share/java/maven-plugin-tools/maven-plugin-plugin.jar

  • xmvn searches for config-files, which are merged in
    • $PWD - which would allow us to create one on the fly based on all inputs
    • $XDG_CONFIG_DIRS and $XDG_DATA_DIRS - which would allow to use native search-path specification

Analysis of repositories behavior:

  • The local repository can consist of a single directory only, I did not find any hint about how to specify several directories. Esp. the "Configuring Maven Guide" [1] and [5] state a single directory only. This makes sense somehow since the local repo is where downloaded files are cached.
  • "Remote" repositories
    • can be specified in settings.xml (and require to pass a profile name when running, e.g. mvn -Pmyprofile) or the pom.xml. Maybe also in .mvn/{settings,extension).xml, I did not test this.
    • repositories are processed *after* the central repository (source: [2])
    • Even if the repository is specified with file://... the artifacts will be copied to the local repo (source: [2], also observed). [3] does not show any option to suppress download.
    • When using "--offline", all remote repositories are disabled, even if specified with file://...
  • Mirrors do not help
    • Can be specified in settings.xml without requiring a profile
    • Even if the mirror is specified with file://... the artifacts will be copied to the local repo (observed, and somehow logically)
  • Some more background about repositories can be found at [4].
  • I also strace'd and ltrace'd several runs of maven to investigate whether there any other env-vars or directories are accessed. Nothing.


Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]