There are three built-in lifecycle: default, clean and site.

if a build phase is called, it will execute not only that build phase, but also every build phase prior to the called build phase.


A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

if a goal is bound to one or more build phases, that goal will be called in all those phases
Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.

If more than one goal is bound to a particular phase, the order used is that those from the packaging are executed first, followed by those configured in the POM. How about those goals in profiles? executed at last?

Default goals in build/default cycle


Set element project > packaging

Each packaging contains a list of goals to bind to a particular phase.

Some of the valid packaging values are jar, war, ear and pom. If no packaging value has been specified, it will default to jar.


See following section for detail.


Besides basic information about the project (e.g. groupId, artifactName, version), some other important elements are:

Information required to build the project.
The lists of the remote repositories for discovering dependencies and extensions.
The lists of the remote repositories for discovering plugins for builds and reports.
This element describes all of the dependencies associated with a project. These dependencies are used to construct a classpath for your project during the build process. They are automatically downloaded from the repositories defined in this project. See the dependency mechanism for more information.
Default dependency information for projects that inherit from this one. The dependencies in this section are not immediately resolved. Instead, when a POM derived from this one declares a dependency described by a matching groupId and artifactId, the version and other values from this section are used for that dependency if they were not already specified.
Distribution information for a project that enables deployment of the site and artifacts to remote web servers and repositories respectively.
Specification for the SCM used by the project, such as CVS, Subversion, etc.
A listing of project-local build profiles which will modify the build process when activated.
The modules (sometimes called subprojects) to build as a part of this project. Each module listed is a relative path to the directory containing the module.
This element includes the specification of report plugins to use to generate the reports on the Maven-generated site. These reports will be run when a user executes mvn site. All of the reports will be included in the navigation bar for browsing.
Properties that can be used throughout the POM as a substitution, and are used as filters in resources if enabled. The format is <name>value</name>.


Plugins are artifacts that provide goals to Maven. Furthermore, a plugin may have one or more goals wherein each goal represents a capability of that plugin.
Note that adding the plugin on its own is not enough information - you must also specify the goals you want to run as part of your build.


Plugins can be managed in element build > pluginManagement and element profiles > profile > build > pluginManagement.

Default plugin information to be made available for reference by projects derived from this one. This plugin configuration will not be resolved or bound to the lifecycle unless referenced. Any local configuration for a given plugin will override the plugin's entire definition here.

Plug Configuration

The most important elements are executions and configuration.
plugin > configuration specifies configuration information that would be shared by all executions of that plugin.
plugin > executions Specifies multiple sets of goals to execute during the build lifecycle, each having (possibly) different configuration by setting plugin > executions > execution > configuration.

The build lifecycle phase to bind the goals in this execution to. If omitted, the goals will be bound to the default specified in their metadata.
The goals to execute with the given configuration.


If the goal is bound to a phase then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it will be executed without executing any phases (as if it was executed in the CLI).

Note that execution id's don't have to be unique. Executions of the same id are merged.

If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated.

There are several ways to trigger a profile. I think the most common ways are

Example: mvn groupId:artifactId:goal -P profile-1,profile-2
Use -P to specify ids of those profiles that would be activated.
system property

Maven help plugin can be used to list all available plugins and active plugins.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License