Package org.apache.maven.api

package org.apache.maven.api

Maven Core API

Dependency management

ArtifactCoordinates instances are used to locate artifacts in a repository. Each instance is basically a pointer to a file in the Maven repository, except that the version may not be defined precisely.

Artifact instances are the pointed artifacts in the repository. They are created when resolving an ArtifactCoordinates. Resolving is the process that selects a particular version and downloads the artifact in the local repository. There are two sub-interfaces, DownloadedArtifact which is used when an artifact has been resolved

DependencyCoordinates instances are used to express a dependency. They are a ArtifactCoordinates completed with information about how the artifact will be used: type, scope and obligation (whether the dependency is optional or mandatory). The version and the obligation may not be defined precisely.

Dependency instances are the pointed dependencies in the repository. They are created when resolving a DependencyCoordinates. Resolving is the process that clarifies the obligation (optional or mandatory status), selects a particular version and downloads the artifact in the local repository.

Node is the main output of the dependency collection process. it's the graph of dependencies. The above-cited Dependency instances are the outputs of the collection process, part of the graph computed from one or more DependencyCoordinates.

DependencyScope defines when/how a given dependency will be used by the project. This includes compile-time only, runtime, test time and various other combinations.

Resolution

Version resolution is the process of finding, for a given artifact, a list of versions that match the input version constraint in the list of remote repositories. This is done either explicitly using the VersionResolver service, or implicitly when resolving an artifact.

Artifact resolution is the process of resolving the version and then downloading the file.

Dependency collection builds a graph of Node objects representing all the dependencies.

The Dependency graph flattening process in Maven involves reducing a complex, multi-level dependency graph to a simpler list where only the most relevant version of each artifact (based on groupId and artifactId) is retained, resolving conflicts and eliminating duplicates to ensure that each dependency is included only once in the final build.

Dependency resolution is the process of collecting dependencies, flattening the result graph, and then resolving the artifacts.

Repositories

In Maven, repositories are locations where project artifacts (such as JAR files, POM files, and other resources) are stored and retrieved. There are two primary types of repositories:

  • local repository: A directory on the developer's machine where Maven caches downloaded artifacts.
  • remote repository: A central or distributed location from which Maven can download artifacts when they are not available locally.

When resolving artifacts, Maven follows this order:

  1. Check Local Repository: Maven first checks if the artifact is available in the local repository.
  2. Check Remote Repositories: If the artifact is not found locally, Maven queries the configured remote repositories in the order they are listed.
  3. Download and Cache: If Maven finds the artifact in a remote repository, it downloads it and stores it in the local repository for future use.

By caching artifacts in the local repository, Maven minimizes the need to repeatedly download the same artifacts, thus optimizing the build process.

Projects

Project instances are loaded by Maven from the local file system (those projects are usually about to be built) or from the local repository (they are usually downloaded during dependency collection). Those projects are loaded from a Project Object Model (POM).

Project Object Model or POM refers to the information describing all the information needed to build or consume a project. Those are usually loaded from a file named pom.xml and loaded into a Model instances.

Project aggregation allows building several projects together. This is only for projects that are built, hence available on the file system. One project, called the aggregator project will list one or more modules which are relative pointers on the file system to other projects. This is done using the /project/modules/module elements of the POM in the aggregator project. Note that the aggregator project is required to have a pom packaging.

Project inheritance defines a parent-child relationship between projects. The child project will inherit all the information from the parent project POM.