To do all those, you only need to call the last build phase to be executed, in this case, 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
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
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
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,
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.