mvn-deploy

Copy the final artifact into the remote repository configured in the settings.xml file

$ mvn deploy

$ mvn deploy:deploy-file [[-D|--define]] url=[URLOfTheRemoteRepository] [[-D|--define]] repositoryId=[ServerIdFromSettingsXML] [[-D|--define]] file=[FileToBeDeployed]

mvn [<options>] deploy
mvn [<options>] deploy -DaltDeploymentRepository=<id>::<layout>::<URL>
mvn [<options>] deploy -Dmaven.deploy.skip=true

-D<property>=<value>
    Sets a system property or Maven property. This is commonly used to pass configuration to the deploy plugin, such as skipping deployment or specifying an alternative repository. Examples include -Dmaven.deploy.skip=true to prevent deployment, or -DaltDeploymentRepository=... for an alternative target.

-P <profiles>
    Activates one or more build profiles by their IDs. Profiles can contain specific configurations for deployment, such as repository URLs or plugin versions, allowing flexible deployment strategies.

-f <file>, --file <file>
    Specifies an alternate path for the project's POM file. By default, Maven looks for pom.xml in the current directory.

-B, --batch-mode
    Runs Maven in non-interactive (batch) mode. This is highly recommended for CI/CD environments where user input is not possible, preventing Maven from prompting for any information.

-U, --update-snapshots
    Forces a check for updated releases and snapshots from remote repositories. This ensures that the build uses the latest versions of dependencies, which can be critical before deploying.

--settings <file>
    Specifies an alternate path for the user settings file (settings.xml). This is useful for providing different repository credentials or mirror configurations for specific deployment scenarios without altering the default settings.

-X, --debug
    Produces execution debug output. In verbose mode, Maven provides detailed information about plugin execution, classpath, and configuration, which is invaluable for troubleshooting deployment issues.

-e, --errors
    Produces execution error messages. This option provides a more detailed stack trace for errors, which can help diagnose problems during the deployment process.

-N, --non-recursive
    Prevents Maven from recursing into sub-projects in a multi-module build. This deploys only the current project's artifacts.

The term "mvn-deploy" is not a standard standalone Linux command. Instead, it refers to the deploy goal within the Maven build lifecycle, executed via the main mvn command (i.e., mvn deploy). This goal is responsible for taking the built project artifacts (like JARs, WARs, POMs, etc.) and copying them to a remote repository. This is a crucial step in continuous integration and continuous deployment (CI/CD) pipelines, making artifacts available for other projects to consume or for final deployment to production environments.

When you run mvn deploy, Maven typically performs the following sequence:

1. Compile: Compiles the project source code.
2. Test: Runs unit tests.
3. Package: Packages the compiled code into a distributable format (e.g., JAR, WAR).
4. Install: Installs the artifact into the local Maven repository, making it available for local projects.
5. Deploy: Finally, it uploads the artifact to the configured remote repository. This repository is typically defined in the project's pom.xml within the <distributionManagement> section and secured with credentials in the user's settings.xml file.

Deployment requires careful configuration of Maven's pom.xml and settings.xml files. The <distributionManagement> section in pom.xml defines the target repositories, while the <servers> section in settings.xml stores the authentication credentials. Storing credentials directly in settings.xml should be done with caution; Maven supports encrypting passwords using its master password feature.

Network connectivity and appropriate write permissions on the remote repository are essential for successful deployment. Deploying release artifacts multiple times to the same repository can sometimes lead to issues if the repository does not support overwrites or if unique versioning is enforced. Snapshot deployments, however, are typically designed to be overwritten.

For mvn deploy to work, two key configuration files are critical. The pom.xml specifies the remote repositories where artifacts should be deployed using the <distributionManagement> section. This section defines <repository> for releases and <snapshotRepository> for snapshots, each with an ID and URL. The settings.xml file (typically in ~/.m2/settings.xml or specified via --settings) then provides the authentication credentials for these repository IDs within its <servers> section. The server ID in settings.xml must match the repository ID in pom.xml for Maven to find the correct credentials.

The deploy goal is the final phase in Maven's standard build lifecycle. When you execute mvn deploy, Maven automatically executes all preceding phases in the default lifecycle up to deploy. This includes validate, compile, test, package, and install. This ensures that the project is fully built, tested, packaged, and installed locally before its artifacts are pushed to the remote repository, guaranteeing that only valid and ready-to-use artifacts are published.

While the primary deployment repository is configured in the pom.xml, Maven allows specifying an alternative deployment target using system properties. For example, -DaltDeploymentRepository=<id>::<layout>::<URL> can be used to override the default repository for a specific deployment. This is particularly useful in CI/CD environments where artifacts might need to be deployed to different staging or release repositories based on the build's context, without modifying the pom.xml.

The deploy goal has been a fundamental part of the Apache Maven build lifecycle since its early days (circa 2004). Its core purpose, to publish project artifacts to remote repositories, has remained consistent. As continuous integration and delivery practices evolved, the deploy goal became a cornerstone for automated build systems like Jenkins, GitLab CI, and GitHub Actions, enabling seamless artifact sharing and management across development teams and stages. Its stability and robust configuration options have made it the de-facto standard for Java project artifact publication.

mvn(1), git(1), curl(1), ssh(1)