Maven Repository Types: Local (.m2), Maven Central and Corporate - Quiz
Total: 6 questions
1. What are a Maven repository and an artifact? How do you derive the file path from the coordinates, and which files are stored in the directory of one version?
What are a Maven repository and an artifact? How do you derive the file path from the coordinates, and which files are stored in the directory of one version?
A Maven repository is a storage of artifacts with a fixed directory layout: Maven takes dependencies and plugins from it and publishes build results to it. An artifact is a file addressed by the Maven coordinates groupId:artifactId:version: a jar, a war, a pom file, a sources archive or Javadoc.
The path is derived from the coordinates: the dots in groupId become directories, followed by the artifactId and version directories, and the file name is artifactId-version.extension. For example, com.google.code.gson:gson:2.11.0 lives at com/google/code/gson/gson/2.11.0/gson-2.11.0.jar - both in ~/.m2/repository and at https://repo.maven.apache.org/maven2. That is why the local, central and corporate repositories share the same layout.
A version directory usually contains:
gson-2.11.0.jar- the artifact itself (.warwhen packaging is war);gson-2.11.0.pom- the POM of the library, from which Maven reads its transitive dependencies; a BOM or a parent POM has only this file;-sources.jarand-javadoc.jar- sources and documentation, downloaded only when requested by the IDE or a command (mvn dependency:sources);*.sha1- checksums used to verify integrity;_remote.repositories- a service file: which repository (by id) the artifact came from;maven-metadata-*.xml- metadata: the list of versions, the latest SNAPSHOT build.
2. What types of repositories does Maven have? Where is the local repository, how do artifacts get into it, and how do you change its path?
What types of repositories does Maven have? Where is the local repository, how do artifacts get into it, and how do you change its path?
Maven has one local repository and any number of remote ones. The local repository is a cache on disk, and Maven checks it first. Every other repository is remote: the central Maven Central (enabled by default), the corporate repository of your company (Nexus, Artifactory) and third-party public ones (for example, https://jitpack.io), which are used only when declared explicitly.
By default the local repository is ~/.m2/repository on Linux and macOS and C:\Users\<name>\.m2\repository on Windows. It belongs to one user and is shared by all of that user’s projects: a library downloaded once is not downloaded again.
Artifacts get there in two ways: Maven downloads them from remote repositories during a build, and mvn install puts the result of your own build there together with its POM. Maven plugins are artifacts too, so the first build of even an empty project downloads dozens of files. A jar that is in no repository is added with mvn install:install-file -Dfile=... -DgroupId=... -DartifactId=... -Dversion=... -Dpackaging=jar.
The directory can be deleted: Maven downloads what it needs again, but your own modules have to be installed again with mvn install. The path is changed permanently with the <localRepository> element in settings.xml, or for one run: mvn package -Dmaven.repo.local=/tmp/m2-clean. An empty directory helps to check whether the project builds "from scratch", as on a CI server.
3. What is Maven Central, where is it declared, how do libraries get there, and how is it different from mvnrepository.com?
What is Maven Central, where is it declared, how do libraries get there, and how is it different from mvnrepository.com?
Maven Central is the public repository Maven uses by default. It is declared in the built-in Super POM with the id central and the URL https://repo.maven.apache.org/maven2, with SNAPSHOT versions disabled (snapshots enabled=false); you can see this declaration in the output of mvn help:effective-pom. There is no need to declare central in your own pom.xml. Practically all open-source Java libraries are published to Central, so most projects need no repository configuration.
You cannot upload an artifact there directly: publishing goes through the Sonatype Central Portal. What is checked is not the code but formal requirements: ownership of the namespace (the groupId is verified through a domain or an account, for example io.github.username), sources and Javadoc archives, PGP signatures, POM metadata (name, description, url, license, developers, scm). A published release can be neither overwritten nor deleted - a fix is shipped as a new version. SNAPSHOT versions are not published to Central.
The official Central search is central.sonatype.com (the old address is search.maven.org). mvnrepository.com is an unofficial catalog: it is convenient for finding libraries and copying a <dependency> snippet, but it does not serve artifacts, so putting its address into <repositories> makes no sense.
4. In what order does Maven search repositories for a dependency? How do you add an extra repository in pom.xml, and when does it make sense?
In what order does Maven search repositories for a dependency? How do you add an extra repository in pom.xml, and when does it make sense?
For every dependency and plugin Maven first checks the local repository; if the file is there (and it is not a SNAPSHOT due for an update check), no network access is needed. Otherwise the remote repositories are queried one by one until one returns the artifact:
- repositories from active profiles in
settings.xml(the global one, then the user one); - repositories from the project
pom.xml, then from parent POMs, and last -centralfrom the Super POM; - repositories declared in the POM files of dependencies.
The file found is stored in the local repository. If a mirror is configured for a repository, the request goes to the mirror URL. In the log line Downloading from central: ... the word after from is the id of the repository the file actually came from. A failure is cached too (*.lastUpdated): until the update interval passes Maven does not look for the artifact again; the -U flag forces a re-check.
An extra repository is declared in <repositories>: a unique id, a url, and <releases> and <snapshots> elements with enabled and updatePolicy (always, daily by default, interval:N, never). Plugins use a separate <pluginRepositories> section. This makes sense for an open-source project that needs a third-party public repository: the project then builds for anyone. Inside a company the corporate repository URL is set once, as a mirror in settings.xml. Usernames and passwords never go into pom.xml: the file ends up in Git. Every extra repository slows down the lookup of missing artifacts.
5. What is configured in settings.xml for working with repositories? How do mirror and server work?
What is configured in settings.xml for working with repositories? How do mirror and server work?
settings.xml is the Maven configuration file of a specific machine, not of a project: the user file ~/.m2/settings.xml and the global conf/settings.xml in the Maven installation directory (when both set the same thing, the user file wins). The main elements:
localRepository- the path to the local repository;mirrors/mirror- replaces the URL of one or all remote repositories;servers/server- username and password (or token) for the repository or mirror with the same id;proxies/proxy- an HTTP proxy for internet access;profiles,activeProfiles- additional repositories and properties for all projects;offline- permanent offline mode (same as-o).
Values of mirrorOf: * - all repositories; central - Maven Central only; external:* - everything except local addresses; a list with exclusions, for example *,!jitpack. A * mirror also captures the repositories from the project <repositories> - the log then shows the mirror id.
Maven takes credentials from the server whose id matches the id of the mirror or repository; if they do not match, the server answers 401 Unauthorized. The password can be taken from environment variables (${env.NEXUS_PASSWORD}) or encrypted with mvn --encrypt-password (this needs a master password in ~/.m2/settings-security.xml). Which settings were actually applied is shown by mvn help:effective-settings.
6. What is a corporate repository (Nexus, Artifactory), and how are artifacts published to it? What is the difference between mvn install and mvn deploy?
What is a corporate repository (Nexus, Artifactory), and how are artifacts published to it? What is the difference between mvn install and mvn deploy?
A corporate repository is a remote repository on a company server that stores the company’s own artifacts and caches public ones. The most common products are Sonatype Nexus Repository and JFrog Artifactory; Maven repositories are also offered by GitHub Packages and GitLab Package Registry. The server usually hosts three types of repositories (in Artifactory - local, remote, virtual):
- hosted - stores the team artifacts published with
mvn deploy(maven-releases, maven-snapshots); - proxy - caches a remote repository: the first request downloads the file from Central, later requests are served by the company server;
- group - combines several repositories under one URL; this is the URL you put into the mirror.
It gives sharing of internal libraries, private code, speed and builds independent of the internet, and control over vulnerable libraries and licenses. To connect, a mirror and a server in settings.xml are enough.
mvn install copies the artifact with its POM only into the local ~/.m2/repository - only projects on this machine can use it. mvn deploy does the same and additionally uploads the artifact to the remote repository from <distributionManagement>: <repository> for releases and <snapshotRepository> for SNAPSHOT versions (Maven picks one by the version suffix); the login comes from the server with the same id. Deploy is usually run by the CI server after a successful build. A SNAPSHOT is stored in the remote repository with a timestamp (shop-1.0-20261107.101530-1.jar), and a release in a hosted repository cannot be overwritten by default. A third-party jar is published with mvn deploy:deploy-file and the -Durl and -DrepositoryId parameters.