Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


To do all those, you only need to call the last build phase to be executed, in this case, deploy.


mvn deploy

That is because if you call a build phase, it will execute not only that build phase, but also every build phase
prior to the called build phase. Thus, doing


mvn integration-test

Will do every build phase before it (validate, compile, package), before executing integration-test.


It should also be noted that the same command can be used in a multi-module scenario (i.e. a project with one or more
subprojects). For example;


mvn clean install

This command will traverse into all of the subprojects and run clean, then install (including all of
the prior steps).


A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a
project. It may bound itself to zero or more build phases. And a goal not bound to any build phase executes outside of
the build lifecycle. The order of execution depends on the order in which the goal(s) and the build phase(s) are
invoked. For exmaple, the in command below. The clean and package arguments are build phases. While the
dependency:copy-dependencies is a goal.


mvn clean dependency:copy-dependencies package

If this were to be executed, the clean phase will first be executed (meaning it will run all preceeding phases,
plus the clean phase itself), and then the dependency:copy-dependencies goal, before finally executing the
package phase (and all its preceeding build phases).



validate the project is correct and all necessary information is available.


initializes the build process


generate any source code for inclusion in compilation.


process the source code, for example to filter any values.


generate resources for inclusion in the package.


copy and process the resources into the destination directory, ready for packaging.


compile the source code of the project.


post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.


generate any test source code for inclusion in compilation.


process the test source code, for example to filter any values.


create resources for testing.


copy and process the resources into the test destination directory.


compile the test source code into the test destination directory


run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.


take the compiled code and package it in its distributable format, such as a JAR.


perform actions required before integration tests are executed. This may involve things such as setting up the required environment.


process and deploy the package if necessary into an environment where integration tests can be run.


perform actions required after integration tests have been executed. This may including cleaning up the environment.


run any checks to verify the package is valid and meets quality criteria.


install the package into the local repository, for use as a dependency in other projects locally.


done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.