17 Basic Maven Commands: A Cheat Sheet

Maven Commands and Options

Apache Maven has remained the dominant build and dependency management tool for Java projects since the mid-2000s. Enterprises and open-source maintainers rely on Maven to orchestrate everything from simple library builds to complex multi module project configurations spanning dozens of interconnected modules. If you’ve worked with Java professionally, you’ve almost certainly encountered a Maven project at some point.

At its core, a Maven command is simply a line starting with mvn that triggers one or more lifecycles, phases, or plugin goals. When you type something like mvn compile or mvn test into your terminal, you’re instructing Maven to execute a specific point in its build life cycle. The mvn command serves as the entry point to Maven’s entire automation system, reading your project’s pom xml file to understand dependencies, plugins, and build configuration.

The main use cases for Maven commands include compiling source code across Java version 8 through 21, running unit tests and integration tests, packaging artifacts into distributable format like JAR or WAR files, and deploying to local repository or remote repository locations. Developers typically run these commands from a terminal in the directory containing the project’s xml file (the pom.xml), whether on Windows cmd or Powershell, Mac OS, or Linux.

In this article, you’ll learn how common Maven commands work and when to use them in real-world Java projects. Towards the end of the article, you'll find a full cheat sheet of Maven command syntaxes here. We hope this will build your conceptual understanding so that any Maven command you encounter makes sense at first glance.

What are Maven lifecycles, phases, and goals?

Maven’s power comes from three interconnected concepts: lifecycles, phases, and goals. Understanding this hierarchy is essential before you start running Maven commands in any meaningful way.

Lifecycles represent broad workflows. Maven ships with three built-in lifecycles:

Lifecycle Purpose
default Build, test, and deploy your compiled code
clean Remove build outputs from the target directory
site Generate documentation and project reports

Each lifecycle is composed of ordered phases that represent discrete stages in the build process. For example, the default lifecycle includes phases like validate, compile, test, package, verify, install, and deploy. When you invoke a phase, Maven automatically executes all preceding phases in that lifecycle—this is why a single command can appear to “do everything.”

Goals are the smallest units of work, provided by Maven plugins. The Maven compiler plugin, for instance, provides goals for compiling Java source classes. The Maven dependency plugin offers goals for analyzing your dependency tree and identifying transitive dependencies. Goals are what actually perform tasks, like transforming test source code into test classes or copying dependencies into your build classpath.

Here's a key insight: when you run a phase like mvn package, you’re not running a single action. You’re triggering every goal bound to that phase and all earlier phases in the lifecycle.

This structure explains why running Maven in a modern Spring, Jakarta EE, or microservice project feels almost magical. One command coordinates validation, compilation, testing, and packaging without manual intervention.

Maven command structure

A typical Maven command follows a predictable structure: the mvn executable, followed by one or more phase or goal names, plus optional flags and system property values.

Maven interprets each part of the command line in sequence:

  1. Global options come first (such as debug mode flags, offline mode switches, or command line parameters that modify behavior)
  2. Phases or goals follow, listed in the order you want them executed
  3. System properties can be passed with -D syntax to override configuration

When you invoke a phase from the default lifecycle, Maven automatically runs all earlier phases. This means running mvn verify will first execute validate, compile, test, and package before reaching the verify phase where quality criteria checks typically occur. You rarely need to specify the lifecycle name explicitly—invoking clean or site is enough for those lifecycles, while phases like compile or install implicitly reference the default lifecycle.

In multi-module project setups (common in large organizations since around 2010 and still standard today), a single command can trigger coordinated builds across dozens of modules. Maven reads the project structure, identifies module dependencies, and executes phases in the correct order—sometimes even parallelizing independent modules for faster builds.

Understanding the main Maven lifecycles

The three core lifecycles handle distinct categories of work in any Maven build.

The default lifecycle

The default lifecycle is responsible for transforming source code and resources into tested, versioned artifacts ready to be installed or deployed. Its 23 phases (far more than the simplified “six phases” often cited) include:

  • validate: Verifies the project’s pom is correct and all necessary information is available
  • compile: Compiles the Java source classes in src/main/java
  • test: Runs unit tests using a suitable unit testing framework
  • package: Packages compiled source code into a final package (JAR, WAR, etc.)
  • verify: Runs checks to verify the package meets quality criteria
  • install: Installs the package to the local Maven repository
  • deploy: Copies the final package to a remote Maven repositories for sharing with other projects
  • When you run mvn install, every phase from validate through install executes. The command deploys nothing to remote repositories—that requires mvn deploy.

    The clean lifecycle

    The clean lifecycle focuses purely on removing the target directory and previously generated artifacts. Its three phases (pre-clean, clean, post-clean) ensure a fresh build environment.

    Running mvn clean before critical actions—such as release builds or reproducible CI pipelines—eliminates stale artifacts that could mask issues like classpath pollution or outdated compiled code.

    The site lifecycle

    The site lifecycle generates static documentation sites into the site directory under target. It produces HTML pages incorporating Javadoc, test reports, coverage summaries, and dependency tree visualizations.

    In a typical Java project, like a Spring Boot microservice, developers interact most with the default and clean lifecycles during daily development and CI/CD workflows. The site lifecycle becomes valuable for open-source projects or internal documentation portals.

    17 basic Maven commands

    This cheat sheet covers the Maven commands you'll actually use in daily development. We give you practical syntax for common tasks: building projects, managing dependencies, running tests, handling plugins, and troubleshooting builds.

    Each command includes the flags and options that make it useful in real scenarios. Whether you need to skip tests for a quick build, force dependency updates, or debug classpath issues, the syntax is here.

    Here is a list of the most employed Maven commands:

    #1: mvn version

    This mvn command line helps us identify which Maven version is installed.

    mvn -v

    #2: mvn package

    This command is used to execute all Maven phases until the package phase. The mvn package compiles, verifies, and builds the project.

    Additionally, the mvn package creates the JAR file and places it in a specific folder under a specific folder.

    mvn package

    #3: mvn clean install

    This Maven command line aids in executing a clean build lifecycle and installs the build phase in the default build cycle. This build lifecycle may have its build phases, and there are different build goals within each build.

    mvn clean install

    The mvn clean install command ensures that the build target is removed for a new build and adds the mvn clean install target.

    #4: mvn compile

    The Maven command: mvn compile is used to compile the source code. The mvn compile compiles the classes stored at a particular target or a class.

    The mvn compile is similar to the previous mvn compiler: compile command, but it runs the entire Maven life cycle up to compile. You can transform the Java files into class files along with the maven compiler plugin itself.

    mvn compile

    #5: mvn test

    This maven command cleans the target directory and also provides the facility of unit tests for particular codes. Therefore, the mvn test command line option runs the tests using suitable testing frameworks.

    If you want to run a test on a single test on your project, you can create a Maven run configuration for a single test with this command.

    mvn test

    #6: mvn deploy

    Maven also has the facility of deploying the code for a project. This deployment is done in an integration or release environment.

    It copies all final packages to the remote repository and becomes available for sharing with other developers.

    mvn deploy

    #7: mvn site

    This Maven command line builds a site that is based upon the information of the project's pom. Maven executes the generated document, which can be seen under the target or the site.

    mvn site

    #8: mvn validate

    This Maven command validates the project to ensure everything is correct and all the necessary information is available.

    The command executes each lifecycle phase in order before executing verify. You must call the last phase to be executed, and in some cases, it can be similar to the mvn package command.

    mvn validate

    #9: mvn dependency tree

    This Maven command displays the dependency tree for a project. Run this in your terminal to view yours.

    mvn dependency tree

    #10: mvn dependency analyze

    This command line analyzes the Maven project to identify the unused declared or used undeclared dependencies.

    It also helps reduce the build size by identifying the unused dependencies and removing them from the XML and pom files.

    mvn dependency analyze

    #11: mvn clean package

    The mvn clean package command clears the target directory. It builds the project and packages in the resulting JAR file into the target directory without running unit tests during the build.

    mvn clean package

    #12: mvn archetype generates

    This Maven command line generates a skeleton for projects of different types, such as website applications, Maven websites, JAR, etc.

    mvn archetype generate

    #13: mvn verify

    This Maven command builds projects, runs all the test cases, and runs any checks on the results of the integration tests to ensure the quality criteria are met.

    mvn verify

    #14: mvn install

    The Maven command: mvn install is used to build a Maven project, and mvn installs all project files, such as JAR file, WAR, POM, etc., to the local repository.

    mvn install

    #15: mvn q package

    This command line option runs the Maven build in quiet mode so that only the test case results and errors are shown.

    mvn q package

    #16: mvn x package

    This command line option prints the Maven version information and runs the build in debug mode so that all messages are displayed.

    mvn x package

    #17: mvn clean

    The mvn clean command cleans the project and then rebuilds it. The mvn clean command runs a clean build life cycle made out of the plugin goal clean: clean.

    mvn clean

    Best practices for working with Maven commands

    Following established conventions makes Maven commands predictable across teams and environments.

    Run Maven from the correct directory. Execute commands from the directory where the primary pom.xml is located. Maven expects the standard project structure (src/main/java, src/test/java, etc.) following convention-over-configuration principles.

    Standardize on a minimal command set. Document a small set of well-understood commands for your team. New joiners in large Java teams shouldn’t need to memorize dozens of variations—a few standard commands (build classpath prints, test, package, install) cover most scenarios.

    Avoid unnecessary clean cycles. Running mvn clean before every local change significantly slows development on large codebases. Reserve full rebuilds for situations where you suspect stale artifacts or after significant branch switches.

    Document versions explicitly. Check and document the Maven version and Java version used by the project. Mismatched versions cause subtle, frustrating failures.

    Use Maven Wrapper. Integrating Maven Wrapper scripts (mvnw) into repositories ensures all contributors and CI jobs share the same maven version, improving determinism. The Maven home location becomes less relevant when the wrapper handles version management.

    Frequently Asked Questions

    Do I always need to run a full clean before building my Maven project?

    A full clean is helpful before important builds such as release candidates or when switching branches with large structural changes, but it’s overkill for every small edit. Modern IDEs and CI pipelines typically run incremental builds; repeatedly cleaning can slow feedback loops for medium and large projects. Reserve clean operations for cases where you suspect stale artifacts, corrupted class files, or plugin configuration changes.

    Which Maven lifecycle phase is usually run in continuous integration (CI)?

    Many CI pipelines execute a phase late in the default lifecycle—often mvn verify, mvn install, or an equivalent project-specific phase—to ensure all tests and checks run. Choosing a later phase ensures earlier phases like validation, compilation, and unit tests execute automatically. Teams should document the agreed-upon phase for CI so developers can reproduce the same behavior locally when diagnosing failures.

    What is the difference between invoking a phase and invoking a plugin goal directly?

    Running a phase executes all goals bound to that phase and all earlier phases in the lifecycle. Running a goal directly (like mvn compiler:compile from the compiler plugin or mvn archetype:generate from mvn archetype) only triggers that specific plugin operation. Phase-based invocations are more common for full builds, while direct goal invocations suit targeted tasks. Beginners should stick to phase-based commands until comfortable with how plugins and goals bind in the effective pom.

    How do Maven profiles affect the commands I run?

    Profiles are named configurations in the pom.xml (or external settings) that toggle features, include extra project dependencies, or adjust plugin behavior. The same base command can behave differently depending on which profiles are active, making profiles powerful for separating dev, test, and production settings. Projects should document which profiles activate for tasks like local debugging, integration tests, and production deployments in a specified project context.

    Is Maven still relevant if my team is adopting newer build tools?

    Maven remains one of the two dominant Java build tools alongside Gradle, deeply integrated into existing enterprise projects. Even if new services use alternative tools, understanding maven commands is essential for maintaining legacy systems and open-source libraries. The conceptual model of lifecycles, phases, and goals carries over to other build tools, so learning Maven builds general build-engineering skills applicable across the ecosystem.

    Why is my build failing due to dependency conflicts?

    Conflicts often occur when two different versions of the same library are requested by different dependencies. Use the mvn dependency:tree command to visualize the project hierarchy and identify where the conflicting versions are coming from.

    How can I skip tests during a build?

    While running tests is recommended, you can skip them by adding the -DskipTests flag to your command. For example: mvn install -DskipTests. This compiles the tests but does not execute them.

    Bruno Mirchevski
    The author
    Bruno Mirchevski

    Bruno Mirchevski is a seasoned hosting industry professional. With years of experience, Bruno is dedicated to helping individuals and businesses find the best web hosting solutions. As a hosting expert at HostAdvice, Bruno provides valuable insights and guidance to users seeking reliable hosting services.