MAVEN Build Life Cycle

The MAVEN Build Lifecycle

CLEAN LIFECYCLE

pre-clean executes processes needed prior to the actual project cleaning

clean remove all files generated by the previous build

post-clean executes processes needed to finalize the project cleaning

PHASE plugin:goalpre-cleanclean clean:cleanpost-clean

DEFAULT LIFECYCLE

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

initialize initialize build state, e.g. set properties or create directories.

generate-sources generate any source code for inclusion in compilation.

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

generate-resources generate resources for inclusion in the package.

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

compile compile the source code of the project.

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

generate-test-sources generate any test source code for inclusion in compilation.

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

generate-test-resources create resources for testing.

process-test-resources copy and process the resources into the test destination directory.

test-compile compile the test source code into the test destination directory

process-test-classes post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.

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

prepare-package perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)

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

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

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

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

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

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

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

PHASE plugin:goal PHASE plugin:goalprocess-resources resources:resources package site:attach-descriptorcompile compiler:compile install install:installprocess-test-resources resources:testResources deploy deploy:deploytest-compile compiler:testCompiletest surefire:test

Cle

an

Lif

ecycle

Packaging Type: JAR Packaging Type: POM

Defa

ult

Lif

ecycle

package jar:jarinstall install:installdeploy deploy:deploy

*JAR is the default packaging type

SITE LIFECYCLE

pre-site executes processes needed prior to the actual project site generationsite generates the project's site documentationpost-site executes processes needed to finalize the site generation, and to prepare for site deploymentsite-deploy deploys the generated site documentation to the specified web server

PHASE plugin:goalpre-sitesite site:sitepost-sitesite-deploy site:deploy

Defa

ult

Lif

ecycle

*POM is the simplest packaging type. The artifact that it generates is itself only. There is no code to test or compile, and there are no resources to process.

Sit

e L

ifecycle

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

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

post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.

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

perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)

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.

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.

PHASE plugin:goal PHASEgenerate-resources plugin:descriptor process-resourcesprocess-resources resources:resources compilecompile compiler:compile process-test-resourcesprocess-test-resources resources:testResources test-compiletest-compile compiler:testCompile test

Packaging Type: maven-plugin Packaging Type: EJB

test surefire:test packagepackage jar:jar, plugin:addPluginArtifactMetadata installinstall install:install, plugin:updateRegistry deploydeploy deploy:deploy

executes processes needed to finalize the site generation, and to prepare for site deployment

*Has goals that generate a descriptor file and perform some modifications to the repository data.

*Though you must configurate the EJB plugin to specifically package for EJB3, else the plugin defaults to 2.1 and looks for the presence of certain EJB configuration files.

perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)

plugin:goal PHASE plugin:goal PHASEresources:resources process-resources resources:resources generate-resourcescompiler:compile compile compiler:compile process-resourcesresources:testResources process-test-resources resources:testResources packagecompiler:testCompile test-compile compiler:testCompile installsurefire:test test surefire:test deploy

Packaging Type: EJB Packaging Type: WAR Packaging Type: EAR

ejb:ejb package war:warinstall:install install install:installdeploy:deploy deploy deploy:deploy

*Though you must configurate the EJB plugin to specifically package for EJB3, else the plugin defaults to 2.1 and looks for the presence of certain EJB configuration files.

*The war:war goal requires a web.xml configuration in your /src/main/webapp/WEB-INF directory.

*The EAR plugin has a goal named generate-application-xml which generates the application.xml based upon the configuration in the EAR project's POM.

plugin:goal PHASE plugin:goalear:generate-application-xml compile flex2:compile-swcresources:resources install install:installear:ear deploy deploy:deployinstall:installdeploy:deploy

Packaging Type: EAR Packaging Type: SWF

*The EAR plugin has a goal named generate-application-xml which generates the application.xml based upon the configuration in the EAR project's POM.

Project Inheritance

SAMPLE 1Directory structure

com.mycompany.app:my-app:1's POM

com.mycompany.app:my-module:1's POM


Project Aggregation


The parent sectionallows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our parent POM.Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.

Elements in the POM that are merged are the following: * dependencies * developers and contributors * plugin lists (including reports) * plugin executions with matching ids * plugin configuration * resources

. |-- my-module | `-- pom.xml `-- pom.xml

<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version></project>

<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version></project>

<project> <parent> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </parent> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version></project>

Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well.

To do Project Aggregation, you must do the following: * Change the parent POMs packaging to the value "pom" . * Specify in the parent POM the directories of its modules (children POMs)



To aggregate my-module into my-app

Project Inheritance vs Project Aggregation



. |-- my-module | `-- pom.xml `-- pom.xml



<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> <packaging>pom</packaging>

<modules> <module>my-module</module> </modules></project>

Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.

And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.

But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules. You'd just have to apply all three rules:

* Specify in every child POM who their parent POM is. * Change the parent POMs packaging to the value "pom" . * Specify in the parent POM the directories of its modules (children POMs)

. |-- my-module | `-- pom.xml `-- parent `-- pom.xml




Grouping Dependencies

SAMPLE 1Consolidating Dependencies in a single POM Project




<modules> <module>../my-module</module> </modules></project>

<project> <parent> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> <relativePath>../parent/pom.xml</relativePath> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>my-module</artifactId></project>

If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. You could create a special POM that does nothing more than declare a set of common dependencies.Since the packaging type is pom, this POM is installed in your local repository. You can now add this project as a dependency and all of its dependencies will be added as transitive dependencies to your project. When you declare a dependency on this persistence-deps project, don't forget to specify the dependency type as pom.

<project> <groupId>org.sonatype.mavenbook</groupId> <artifactId>persistence-deps</artifactId> <version>1.0</version> <packaging>pom</packaging> <dependencies> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> <version>${hibernateVersion}</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-annotations</artifactId> <version>${hibernateAnnotationsVersion}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-hibernate3</artifactId> <version>${springVersion}</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>${mysqlVersion}</version> </dependency> </dependencies> <properties> <mysqlVersion>(5.1,)</mysqlVersion> <springVersion>(2.0.6,)</springVersion> <hibernateVersion>3.2.5.ga</hibernateVersion> <hibernateAnnotationsVersion>3.3.0.ga</hibernateAnnotationsVersion> </properties></project>

Consolidating related dependencies is a good way to cut down on the length of pom.xml files that start having to depend on a large number of dependencies. If you need to share a large number of dependencies between projects, you could also just establish parent-child relationships between projects and refactor all common dependencies to the parent project, but the disadvantage of the parent-child approach is that a project can have only one parent. Sometimes it makes more sense to group similar dependencies together and reference a pom dependency.This way, your project can reference as many of these consolidated dependency POMs as it needs.

Maven uses the depth of a dependency in the tree when resolving conflicts using a nearest-wins approach. Using the dependency grouping technique above pushes those dependencies one level down in the tree. Keep this in mind when choosing between grouping in a pom or using dependencyManagement in a parent POM.






The parent sectionallows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our

Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.




<project> <parent> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> <relativePath>.../parent/pom.xml</relativePath> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>my-module</artifactId></project>

Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven command is invoked against the parent project, that Maven command will then be executed to the parent's modules as well.

* Specify in the parent POM the directories of its modules (children POMs)



To aggregate my-module into my-app





<modules> <module>../my-module</module> </modules></project>

Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.

And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will

But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules.

* Specify in the parent POM the directories of its modules (children POMs)


Declaring a Dependency on a POM

If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. You could create a special POM that does nothing more than declare a set of

Since the packaging type is pom, this POM is installed in your local repository. You can now add this project as a dependency and all of its dependencies will be added as transitive dependencies to your project. When you declare a dependency on this persistence-deps project, don't forget to specify the dependency type as pom.

<project> <description>This is a project requiring JDBC</description> ... <dependencies> ... <dependency> <groupId>org.sonatype.mavenbook</groupId> <artifactId>persistence-deps</artifactId> <version>1.0</version> <type>pom</type> </dependency> </dependencies></project>

Consolidating related dependencies is a good way to cut down on the length of pom.xml files that start having to depend on a large number of dependencies. If you need to share a large number of dependencies between projects, you could also just establish parent-child relationships between projects and refactor all common dependencies to the parent project, but the disadvantage of the parent-child approach is that a project can have only one parent. Sometimes it makes more sense to group similar dependencies together and reference a pom dependency.This way, your project can reference as many of these consolidated dependency POMs as it needs.

Maven uses the depth of a dependency in the tree when resolving conflicts using a nearest-wins approach. Using the dependency grouping technique above pushes those dependencies one level down in the tree. Keep this in mind when choosing between grouping in a pom or using dependencyManagement in a parent POM.

The parent sectionallows us to specify which artifact is the parent of our POM. And we do so by specifying the fully qualified artifact name of the parent POM. With this setup, our module can now inherit some of the properties of our

Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.

*Alternatively, if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.

Project Aggregation is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM. By doing so, the parent project now knows its modules, and if a Maven

Now, whenever a Maven command processes com.mycompany.app:my-app:1, that same Maven command would be ran against com.mycompany.app:my-module:1 as well. Furthermore, some commands (goals specifically) handle

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects

And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will

But of course, you can have both Project Inheritance and Project Aggregation. Meaning, you can have your modules specify a parent project, and at the same time, have that parent project specify those Maven projects as its modules.


If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. You could create a special POM that does nothing more than declare a set of

Since the packaging type is pom, this POM is installed in your local repository. You can now add this project as a dependency and all of its dependencies will be added as transitive dependencies to your project. When you declare a

Consolidating related dependencies is a good way to cut down on the length of pom.xml files that start having to depend on a large number of dependencies. If you need to share a large number of dependencies between projects, you could also just establish parent-child relationships between projects and refactor all common dependencies to the parent project, but the disadvantage of the parent-child approach is that a project can have only one parent. Sometimes it

Maven uses the depth of a dependency in the tree when resolving conflicts using a nearest-wins approach. Using the dependency grouping technique above pushes those dependencies one level down in the tree. Keep this in mind when

Profile activation

Profiles explicitly specified by using the -P CLI option

mvn groupId:artifactId:goal -P profile-1,profile-2

Profiles with activation based on OS settings

Profiles activated when a file is missing

Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). Used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.

What are the different types of profile? Where is each defined?

* Per Project (Defined in the POM itself) * Per User (Defined in the Maven settings.xml) * Global (Defined in the global Mavensettings.xml) * Profile descriptor (A descriptor located in project basedir (profiles.xml) (deprecated in Maven 3.0: see Maven 3 compatibility notes))

A profile can be triggered/activated in several ways:

* Explicitly * Through Maven settings * Based on environment variables * OS settings * Present or missing files

* When this option is specified, no profiles other than those specified in the option argument will be activated.

<profiles> <profile> <activation> <os> <name>Windows XP</name> <family>Windows</family> <arch>x86</arch> <version>5.1.2600</version> </os> </activation> ... </profile></profiles>

All profiles that are active by default are automatically deactivated when a profile in the pom is activated on the command line or through its activation config.

Profile deactivation

Areas of a POM that can be customized by each type of profile

<profiles> <profile> <activation> <file> <missing>target/generated-sources/axistools/wsdl2java/org/apache/maven</missing> </file> </activation> ... </profile></profiles>

* As of Maven 2.0.9, the tags <exists> and <missing> could be interpolated. Supported variables are system properties like ${user.home} and environment variables like ${env.HOME}.

Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below: mvn groupId:artifactId:goal -P !profile-1,!profile-2This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.

Depending on where you choose to configure your profile, you will have access to varying POM configuration options.

Profiles in external filesProfiles specified in external files (i.e in settings.xml or profiles.xml) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the <repositories> and <pluginRepositories> sections, plus an extra <properties> section.The <properties> section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of ${profile.provided.path}.

Profiles in POMsOn the other hand, if your profiles can be reasonably specified inside the POM, you have many more options. The trade-off, of course, is that you can only modify that project and it's sub-modules. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users.

Profiles specified in the POM can modify the following POM elements: * <repositories> * <pluginRepositories> * <dependencies> * <plugins> * <properties> (not actually available in the main POM, but used behind the scenes) * <modules> * <reporting> * <dependencyManagement> * <distributionManagement> * a subset of the <build> element, which consists of: o <defaultGoal> o <resources> o <testResources> o <finalName>

POM elements outside <profiles>We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project completely unique from others. While you can do this to some extent with the options given for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.

External files such as settings.xml and profiles.xml also does not support elements outside the POM-profiles. Let us take this scenario for elaboration. When the effective POM get deployed to a remote repository, any person can pickup its info out of the repository and use it to build a Maven project directly. Now, imagine that if we can set profiles in dependencies, which is very important to a build, or in any other elements outside POM-profiles in settings.xml then most probably we cannot expect someone else to use that POM from the repository and be able to build it. And we have to also think about how to share the settings.xml with others. Note that too many files to configure is very confusing and very hard to maintain. Bottom line is that since this is build data, it should be in the POM. One of the goals in Maven 2 is to consolidate all the information needed to run a build into a single file, or file hierarchy which is the POM.

To test which profiles are active for a given build, use: mvn help:active-profiles

Profiles activated through the Maven settings

Profiles activated when the system property "debug" is set with any v

Profiles activated when the property "environment" is set with the "te

Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). Used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.

* Profile descriptor (A descriptor located in project basedir (profiles.xml) (deprecated in Maven 3.0: see Maven 3 compatibility notes))

<settings> ... <activeProfiles> <activeProfile>profile-1</activeProfile> </activeProfiles> ...</settings>

* Profiles listed in the <activeProfiles> tag would be activated by default every time a project use it.

<profiles> <profile> <activation> <property> <name>debug</name> </property> </activation> ... </profile></profiles>

* The exclamation point is referred to as the "bang" character and signifies "not". So, a profile can be activated when no debug property is set. (<name>!debug</name>)


Areas of a POM that can be customized by each type of profile

<profiles> <profile> <activation> <property> <name>environment</name> <value>test</value> </property> </activation> ... </profile></profiles>

* To activate this you would type this on the command line: mvn groupId:artifactId:goal -Denvironment=test

Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below:

This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.

Depending on where you choose to configure your profile, you will have access to varying POM configuration options.

Profiles specified in external files (i.e in settings.xml or profiles.xml) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the <repositories> and <pluginRepositories> sections, plus an extra

The <properties> section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of ${profile.provided.path}.

On the other hand, if your profiles can be reasonably specified inside the POM, you have many more options. The trade-off, of course, is that you can only modify that project and it's sub-modules. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users.

Profiles specified in the POM can modify the following POM elements:

* <properties> (not actually available in the main POM, but used behind the scenes)

We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project

from others. While you can do this to some extent with the options given for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.

External files such as settings.xml and profiles.xml also does not support elements outside the POM-profiles. Let us take this scenario for elaboration. When the effective POM get deployed to a remote repository, any person can pickup its

repository and use it to build a Maven project directly. Now, imagine that if we can set profiles in dependencies, which is very important to a build, or in any other elements outside POM-profiles in settings.xml then most probably we

someone else to use that POM from the repository and be able to build it. And we have to also think about how to share the settings.xml with others. Note that too many files to configure is very confusing and very hard to maintain.

since this is build data, it should be in the POM. One of the goals in Maven 2 is to consolidate all the information needed to run a build into a single file, or file hierarchy which is the POM.

Profiles triggered based on the detected state of the build environment

Profiles triggered based on the detected state of the build environment

Profiles actived by default

Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). Used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build

<profiles> <profile> <activation> <jdk>1.4</jdk> </activation> ... </profile></profiles>

* This configuration will trigger the profile when the JDK's version starts with "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4")

<profiles> <profile> <activation> <jdk>[1.3,1.6)</jdk> </activation> ... </profile></profiles>

* Ranges can also be used as of Maven 2.1. The above honours versions 1.3, 1.4 and 1.5.


<profiles> <profile> <id>profile-1</id> <activation> <activeByDefault>true</activeByDefault> </activation> ... </profile></profiles>

* This profile will automatically be active for all builds unless another profile in the same pom is activated using one of the previously described methods.

Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character '!' or '-' as shown below:

Profiles specified in external files (i.e in settings.xml or profiles.xml) are not portable in the strictest sense. Anything that seems to stand a high chance of changing the result of the build is restricted to the inline profiles in the POM. Things like repository lists could simply be a proprietary repository of approved artifacts, and won't change the outcome of the build. Therefore, you will only be able to modify the <repositories> and <pluginRepositories> sections, plus an extra

The <properties> section allows you to specify free-form key-value pairs which will be included in the interpolation process for the POM. This allows you to specify a plugin configuration in the form of ${profile.provided.path}.

On the other hand, if your profiles can be reasonably specified inside the POM, you have many more options. The trade-off, of course, is that you can only modify that project and it's sub-modules. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users.

We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project

from others. While you can do this to some extent with the options given for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.

External files such as settings.xml and profiles.xml also does not support elements outside the POM-profiles. Let us take this scenario for elaboration. When the effective POM get deployed to a remote repository, any person can pickup its

repository and use it to build a Maven project directly. Now, imagine that if we can set profiles in dependencies, which is very important to a build, or in any other elements outside POM-profiles in settings.xml then most probably we

someone else to use that POM from the repository and be able to build it. And we have to also think about how to share the settings.xml with others. Note that too many files to configure is very confusing and very hard to maintain.

since this is build data, it should be in the POM. One of the goals in Maven 2 is to consolidate all the information needed to run a build into a single file, or file hierarchy which is the POM.

CONFIGURING MAVEN PLUGINS (Introduction)

GENERIC CONFIGURATION

Setting Global Plugin Parameters

Configuring a maven plugin

Mapping Lists

In Maven, there are the build and the reporting plugins:

* Build plugins will be executed during the build and then, they should be configured in the <build/> element. * Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element.

All plugins should have minimal required informations: groupId, artifactId and version.

Important Note: It is recommended to always defined each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <build><pluginManagement/></build> elements for each build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <reporting><plugins/></reporting> elements (and surely in the <build><pluginManagement/></build> elements too).

Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal).

Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where a Mojo maps to a goal).Unless this configuration is overridden by a more specific plugin parameter configuration, Maven will use the values defined directly under the plugin element for all goals which are executed in this plugin.

<project> ... <build> <plugins> <plugin> <artifactId>maven-myquery-plugin</artifactId> <version>1.0</version> <configuration> <url>http://www.foobar.com/query</url> <timeout>10</timeout> <options> <option>one</option> <option>two</option> <option>three</option> </options> </configuration> </plugin> </plugins> </build> ...</project>

CONFIGURING BUILD PLUGINS

Using the <executions/> Tag

Setting Configuration Parameters in an Execution

<project> ... <build> <plugins> <plugin> <artifactId>maven-myanimal-plugin</artifactId> <version>1.0</version> <configuration> <animals> <animal>cat</animal> <animal>dog</animal> <animal>aardvark</animal> </animals> </configuration> </plugin> </plugins> </build> ...</project>

The rules for mapping complex objects are as follows:

* There must be a private field that corresponds to name of the element being mapped. So in our case the person element must map to a person field in the mojo. * The object instantiated must be in the same package as the Mojo itself. So if your mojo is in com.mycompany.mojo.query then the mapping mechanism will look in that package for an object named Person. As you can see the mechanism will capitalize the first letter of the element name and use that to search for the object to instantiate. * If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an implementation attribute (<person implementation="com.mycompany.mojo.query.SuperPerson">)

Unlike arrays, collections have no specific component type. In order to derive the type of a list item, the following strategy is used:

1. If the XML element contains an implementation hint attribute, that is used 2. If the XML tag contains a ., try that as a fully qualified class name 3. Try the XML tag (with capitalized first letter) as a class in the same package as the mojo/object being configured 4. If the element has no children, assume its type is String. Otherwise, the configuration will fail.

You can also configure a mojo using the <executions> tag. This is most commonly used for mojos that are intended to participate in some phases of the build lifecycle. You can configure plugin parameters for specific executions of a plugin goal

Using the <dependencies/> Tag

Adding dependencies to a plugin

<plugin> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <phase>validate</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <echo>${PATH}=${env.PATH}</echo> <echo>User's Home Directory: ${user.home}</echo> <echo>Project's Base Director: ${basedir}</echo> </tasks> </configuration> </execution> </executions></plugin>

* Example of configuration parameters being passed to the execution of the run goal of the AntRun plugin during the validate phase. This specific execution will inherit the configuration parameters from the plugin's configuration element and merge them with the values defined for this particular execution.

Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.

Note: Configurations inside the <executions> tag differ from those that are outside <executions> in that they cannot be used from a direct command line invocation. Instead they are only applied when the lifecycle phase they are bound to are invoked. Alternatively, if you move a configuration section outside of the executions section, it will apply globally to all invocations of the plugin.

If you need to configure a plugin to use specific versions of dependencies, you can define these dependencies under a dependencies element under plugin. When the plugin executes, it will execute with a classpath that contains these dependencies.You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version.

Using the <inherited/> Tag In Build Plugins

Using the <inherited/> Tag In Build Plugins

Setting Default Command Line Execution Parameters

Starting with Maven 2.2.0, you can now supply configuration parameters for goals which are executed from the command-line. To do this, use the special execution id value of "default-cli".

Configuring Plugin Parameters for Command Line Execution

<plugin> <groupId>com.agilejava.docbkx</groupId> <artifactId>docbkx-maven-plugin</artifactId> <version>2.0.9</version> <dependencies> <dependency> <groupId>docbook</groupId> <artifactId>docbook-xml</artifactId> <version>4.5</version> </dependency> <dependency> <groupId>org.apache.fop</groupId> <artifactId>fop-pdf-images</artifactId> <version>1.3</version> </dependency> <dependency> <groupId>org.apache.fop</groupId> <artifactId>fop-pdf-images-res</artifactId> <version>1.3</version> <classifier>res</classifier> </dependency> <dependency> <groupId>pdfbox</groupId> <artifactId>pdfbox</artifactId> <version>0.7.4-dev</version> <classifier>dev</classifier> </dependency> </dependencies></plugin>

* Example of a plugin configuration that overrides default dependency versions and adds new dependencies to facilitate goal execution.

By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited/> tag

<project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.2</version> <inherited>false</inherited> ... </plugin> </plugins> </build> ...</project>

Setting Parameters for Goals Bound to Default Lifecycle

Setting a Parameter for a Default Goal Execution

<plugin> <artifactId>maven-assembly-plugin</artifactId> <configuration> <appendAssemblyId>false</appendAssemblyId> </configuration> <executions> <execution> <id>assemble-binary</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <descriptors> <descriptor>src/main/assembly/bin.xml</descriptor> </descriptors> </configuration> </execution> <execution> <id>default-cli</id> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> </execution> </executions></plugin>

* Example that binds the single goal to the package phase of the lifecycle which produces a binary distribution. This example also configures the default-cli execution for the assembly plugin to use the jar-with-dependencies assembly descriptor.The bin.xml descriptor will be used during the lifecycle, and jar-with-dependencies will be used when you execute mvn assembly:assembly from the command line.

Starting with Maven 2.2.0, if you need to customize the behavior of a goal which is already bound to the default lifecycle, you can use the execution id "default-<goal>". You can customize the behavior of the Jar plugin's jar goal which is bound to the package phase in the default lifecycle, and you can customize the configuration parameters of a separate goal execution.

Configuring the default goal execution parameters can also come in handy if you need to configure two goals bound to the default lifecycle with separate settings for the same configuration parameter.

CONFIGURING REPORTING PLUGINS

Using the <reportSets/> TagYou can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site.

Using the <reportSets/> Tag

* This example will generate only the project team report.

<plugin> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <id>default-jar</id> <configuration> <excludes> <exclude>**/somepackage/*</exclude> </excludes> </configuration> </execution> <execution> <id>special-jar</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> <configuration> <includes> <include>**/sompackage/*</include> </includes> <classifier>somepackage</classifier> </configuration> </execution> </executions></plugin>

* In this example, the default jar goal is customized to exclude contents in a specific package. Another jar goal is bound to the package phase to create a JAR file which contains only the contents of a particular package in a classified JAR file.

<project> ... <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> <version>2.1.2</version> <reportSets> <reportSet> <reports> <report>project-team</report> </reports> </reportSet> </reportSets> </plugin> </plugins> </reporting> ...</project>

Using the <inherited/> Tag In Reporting PluginsSimilar to the build plugins, to break the inheritance, you could uses the <inherited/> tag:

Using the <inherited/> Tag In Reporting Plugins

Using the <reporting/> Tag VS <build/> Tag

Notes: 1. To exclude all reports, you need to use: <reportSets> <reportSet> <reports/> </reportSet> </reportSets>

2. Refer to each Plugin Documentation (i.e. plugin-info.html) to know the available report goals.

<project> ... <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-project-info-reports-plugin</artifactId> <version>2.1.2</version> <inherited>false</inherited> </plugin> </plugins> </reporting> ...</project>

Configuring a reporting plugin in the <reporting/> or <build/> elements in the pom have NOT the same behavior!

mvn site It uses only the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element, i.e. site always ignores the parameters defined in the <configuration/> element of each plugin specified in <build/>.

mvn aplugin:areportgoal It uses firstly the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element; if a parameter is not found, it will look up to a parameter defined in the <configuration/> element of each plugin specified in <build/>.

Mapping Simple Objects

Mapping Maps

* Build plugins will be executed during the build and then, they should be configured in the <build/> element.* Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element.

All plugins should have minimal required informations: groupId, artifactId and version.

It is recommended to always defined each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <build><pluginManagement/></build> elements for each build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <reporting><plugins/></reporting> elements (and surely in the

Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in

Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in

Unless this configuration is overridden by a more specific plugin parameter configuration, Maven will use the values defined directly under the plugin element for all goals which are executed in this plugin.

...<configuration> <myString>a string</myString> <myBoolean>true</myBoolean> <myInteger>10</myInteger> <myDouble>1.0</myDouble> <myFile>c:\temp</myFile> <myURL>http://maven.apache.org</myURL></configuration>...


... <configuration> <myMap> <key1>value1</key1> <key2>value2</key2> </myMap> </configuration>…

* There must be a private field that corresponds to name of the element being mapped. So in our case the person element must map to a person field in the mojo.* The object instantiated must be in the same package as the Mojo itself. So if your mojo is in com.mycompany.mojo.query then the mapping mechanism will look in that package for an object named Person. As you can

see the mechanism will capitalize the first letter of the element name and use that to search for the object to instantiate.* If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an implementation attribute (<person

have no specific component type. In order to derive the type of a list item, the following strategy is used:

1. If the XML element contains an implementation hint attribute, that is used2. If the XML tag contains a ., try that as a fully qualified class name3. Try the XML tag (with capitalized first letter) as a class in the same package as the mojo/object being configured4. If the element has no children, assume its type is String. Otherwise, the configuration will fail.

tag. This is most commonly used for mojos that are intended to participate in some phases of the build lifecycle. You can configure plugin parameters for specific executions of a plugin goal

Adding dependencies to a plugin

<project> ... <build> <plugins> <plugin> <artifactId>maven-myquery-plugin</artifactId> <version>1.0</version> <executions> <execution> <id>execution1</id> <phase>test</phase> <configuration> <url>http://www.foo.com/query</url> <timeout>10</timeout> <options> <option>one</option> <option>two</option> <option>three</option> </options> </configuration> <goals> <goal>query</goal> </goals> </execution> <execution> <id>execution2</id> <configuration> <url>http://www.bar.com/query</url> <timeout>15</timeout> <options> <option>four</option> <option>five</option> <option>six</option> </options> </configuration> <goals> <goal>query</goal> </goals> </execution> </executions> </plugin> </plugins> </build> ...</project>* The first execution with id "execution1" binds this configuration to the test phase. The second execution does not have a <phase> tag, how do you think will this execution behave? Well, goals can have a default phase binding as discussed further below. If the goal has a default phase binding then it will execute in that phase. But if the goal is not bound to any lifecycle phase then it simply won't be executed during the build lifecycle.

Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are merged. The same applies to executions that are defined by profiles.

Configurations inside the <executions> tag differ from those that are outside <executions> in that they cannot be used from a direct command line invocation. Instead they are only applied when the lifecycle phase they are bound to are invoked. Alternatively, if you move a configuration section outside of the executions section, it will apply globally to all invocations of the plugin.

If you need to configure a plugin to use specific versions of dependencies, you can define these dependencies under a dependencies element under plugin. When the plugin executes, it will execute with a classpath that contains these

You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version.

Setting Default Command Line Execution Parameters


<project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.2</version> ... <dependencies> <dependency> <groupId>org.apache.ant</groupId> <artifactId>ant</artifactId> <version>1.7.1</version> </dependency> <dependency> <groupId>org.apache.ant</groupId> <artifactId>ant-launcher</artifactId> <version>1.7.1</version> </dependency> </dependencies> </plugin> </plugins> </build> ...</project>

* The Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <dependencies/> element like above

By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited/> tag

Setting Parameters for Goals Bound to Default Lifecycle

Setting Two Default Goal Plugin Configuration Parameters

Starting with Maven 2.2.0, if you need to customize the behavior of a goal which is already bound to the default lifecycle, you can use the execution id "default-<goal>". You can customize the behavior of the Jar plugin's jar goal which is bound to the package phase in the default lifecycle, and you can customize the configuration parameters of a separate goal execution.


You can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site.

<plugin> <artifactId>maven-resources-plugin</artifactId> <executions> <execution> <id>default-resources</id> <configuration> <includeEmptyDirs>false</includeEmptyDirs> </configuration> </execution> <execution> <id>default-testResources</id> <configuration> <includeEmptyDirs>true</includeEmptyDirs> </configuration> </execution> </executions></plugin>

* This example configures the default resources:resources goal to exclude empty directories while configuring the default resources:testResources goal to include empty directories.

Similar to the build plugins, to break the inheritance, you could uses the <inherited/> tag:

2. Refer to each Plugin Documentation (i.e. plugin-info.html) to know the available report goals.

Configuring a reporting plugin in the <reporting/> or <build/> elements in the pom have NOT the same behavior!

It uses only the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element, i.e. site always ignores the parameters defined in the <configuration/> element of each plugin

It uses firstly the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element; if a parameter is not found, it will look up to a parameter defined in the <configuration/> element of

Mapping Complex Objects

Mapping Properties

It is recommended to always defined each version of the plugins used by the build to guarantee the build reproducibility. A good practice is to specify them in the <build><pluginManagement/></build> elements for each build plugins (generally, you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <reporting><plugins/></reporting> elements (and surely in the

element where the child elements of the <configuration/> element are mapped to fields, or setters, inside your Mojo (remember that a plug-in

element are mapped to fields, or setters, inside your Mojo (remember that a plug-in

Unless this configuration is overridden by a more specific plugin parameter configuration, Maven will use the values defined directly under the plugin element for all goals which are executed in this plugin.

...<configuration> <person> <firstName>Jason</firstName> <lastName>van Zyl</lastName> </person></configuration>…


... <configuration> <myProperties> <property> <name>propertyName1</name> <value>propertyValue1</value> <property> <property> <name>propertyName2</name> <value>propertyValue2</value> <property> </myProperties> </configuration>...

* There must be a private field that corresponds to name of the element being mapped. So in our case the person element must map to a person field in the mojo.* The object instantiated must be in the same package as the Mojo itself. So if your mojo is in com.mycompany.mojo.query then the mapping mechanism will look in that package for an object named Person. As you can

* If you wish to have the object to be instantiated live in a different package or have a more complicated name then you must specify this using an implementation attribute (<person

tag. This is most commonly used for mojos that are intended to participate in some phases of the build lifecycle.

<project> ... <build> <plugins> <plugin> <artifactId>maven-myquery-plugin</artifactId> <version>1.0</version> <executions> <execution> <id>execution1</id> <phase>test</phase> <configuration> <url>http://www.foo.com/query</url> <timeout>10</timeout> <options> <option>one</option> <option>two</option> <option>three</option> </options> </configuration> <goals> <goal>query</goal> </goals> </execution> <execution> <id>execution2</id> <phase>install</phase> <configuration> <url>http://www.bar.com/query</url> <timeout>15</timeout> <options> <option>four</option> <option>five</option> <option>six</option> </options> </configuration> <goals> <goal>query</goal> </goals> </execution> </executions> </plugin> </plugins> </build> ...</project>* If there are multiple executions bound to different phases, then the mojo is executed once for each phase indicated. Meaning, execution1 will be executed applying the configuration setup when the phase of the build is test, and execution2 will be executed applying the configuration setup when the build phase is already in install.

Note that while execution id's have to be unique among all executions of a single plugin within a POM, they don't have to be unique across an inheritance hierarchy of POMs. Executions of the same id from different POMs are

Configurations inside the <executions> tag differ from those that are outside <executions> in that they cannot be used from a direct command line invocation. Instead they are only applied when the lifecycle phase they are bound to are invoked. Alternatively, if you move a configuration section outside of the executions section, it will apply globally to all invocations of the plugin.

If you need to configure a plugin to use specific versions of dependencies, you can define these dependencies under a dependencies element under plugin. When the plugin executes, it will execute with a classpath that contains these


Starting with Maven 2.2.0, if you need to customize the behavior of a goal which is already bound to the default lifecycle, you can use the execution id "default-<goal>". You can customize the behavior of the Jar plugin's jar goal which is


You can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site.

Similar to the build plugins, to break the inheritance, you could uses the <inherited/> tag:

It uses only the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element, i.e. site always ignores the parameters defined in the <configuration/> element of each plugin

It uses firstly the parameters defined in the <configuration/> element of each reporting Plugin specified in the <reporting/> element; if a parameter is not found, it will look up to a parameter defined in the <configuration/> element of

Maven Properties

Maven Project Properties

Propertyproject.groupIdproject.versionproject.artifactIdproject.nameproject.descriptionproject.build.sourceDirectoryproject.build.scriptSourceDirectoryproject.build.testSourceDirectoryproject.build.outputDirectoryproject.build.testOutputDirectoryproject.build.directorybasedir

project.baseUri

maven.build.timestamp……

Maven Settings Properties

Environment Variable PropertiesEnvironment variables can be referenced with the env.* prefix. Some interesting environment variables are listed in the following list:

Property

env.PATH

env.HOMEenv.JAVA_HOMEenv.M2_HOME……

You can use Maven properties in a pom.xml file or in any resource that is being processed by the Maven Resource plugin's filtering features. A property is always surrounded by ${ and }. For example, to reference the project.version property, one would write: ${project.version}

There are some implicit properties available in any Maven project, these implicit properties are:project.* >> Maven Project Object Model (POM). You can use the project.* prefix to reference values in a Maven POM.settings.* >> Maven Settings. You use the settings.* prefix to reference values from your Maven Settings in ~/.m2/settings.xml.env.* >> Environment variables like PATH and M2_HOME can be referenced using the env.* prefix.System Properties >> Any property which can be retrieved from the System.getProperty() method can be referenced as a Maven property.

In addition to the implicit properties listed above, a Maven POM, Maven Settings, or a Maven Profile can define a set of arbitrary, user-defined properties. The following sections provide some detail on the various properties available in a Maven project.

When a Maven Project Property is referenced, the property name is referencing a property of the Maven Project Object Model (POM). Specifically, you are referencing a property of the org.apache.maven.model.Model class which is being exposed as the implicit variable project. When you reference a property using this implicit variable, you are using simple dot notation to reference a bean property of the Model object. For example, when you reference ${project.version}, you are really invoking the getVersion() method on the instance of Model that is being exposed as project.The POM is also represented in the pom.xml document present in all Maven projects. Anything in a Maven POM can be referenced with a property. The following list shows some common property references from the Maven project.

* A complete reference for the POM structure is available at http://maven.apache.org/ref/2.2.1/mavenmodel/maven.html* For a full list of properties available on the Maven Model object, take a look at the JavaDoc for the maven-model project here http://maven.apache.org/ref/2.2.1/maven-model/apidocs/index.html

You can also reference any properties in the Maven Local Settings file which is usually stored in ~/.m2/settings.xml. This file contains user-specific configuration such as the location of the local repository and any servers, profiles, and mirrors configured by a specific user.

A full reference for the Local Settings file and corresponding properties is available here http://maven.apache.org/ref/2.2.1/mavensettings/settings.html

While they are available, you should always use the Java System properties if you have the choice. If you need a user's home directory use ${user.home} instead of ${env.HOME}. If you do this, you'll end up with a more portable build that is more likely to adhere to the Write-Once-Run-Anywhere (WORA) promise of the Java platform.

Java System PropertiesMaven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() you can reference in a Maven property. The following table lists available properties:

Propertyjava.version java.vendor java.vendor.url java.home java.vm.specification.version java.vm.specification.vendor java.vm.specification.name java.vm.version java.vm.vendor java.vm.name java.specification.version java.specification.vendor java.specification.namejava.class.versionjava.class.pathjava.ext.dirsos.nameos.archos.versionfile.separatorpath.separatorline.separatoruser.nameuser.homeuser.dir

User-defined Propertiesyou have the ability to define your own arbitrary properties. Properties can be defined in a POM or in a Profile. The properties set in a POM or in a Maven Profile can be referenced just like any other property available throughout Maven. User-defined properties can be referenced in a POM, or they can be used to filter resources via the Maven Resource plugin.

<project>...<properties><arbitrary.property.a>This is some text</arbitrary.property.a><hibernate.version>3.3.0.ga</hibernate.version></properties>...<dependencies><dependency><groupId>org.hibernate</groupId><artifactId>hibernate</artifactId><version>${hibernate.version}</version></dependency></dependencies>...</project>

Description

The directory that the current project resides in.

The timestamp that denotes the start of the build. Since Maven 2.1.0-M1

Environment variables can be referenced with the env.* prefix. Some interesting environment variables are listed in the following list:

Description

Contains the Maven 2 installation directory.

You can use Maven properties in a pom.xml file or in any resource that is being processed by the Maven Resource plugin's filtering features. A property is always surrounded by ${ and }. For example, to reference the project.version

There are some implicit properties available in any Maven project, these implicit properties are:>> Maven Project Object Model (POM). You can use the project.* prefix to reference values in a Maven POM.>> Maven Settings. You use the settings.* prefix to reference values from your Maven Settings in ~/.m2/settings.xml.>> Environment variables like PATH and M2_HOME can be referenced using the env.* prefix.

>> Any property which can be retrieved from the System.getProperty() method can be referenced as a Maven property.

In addition to the implicit properties listed above, a Maven POM, Maven Settings, or a Maven Profile can define a set of arbitrary, user-defined properties. The following sections provide some detail on the various properties available in a

When a Maven Project Property is referenced, the property name is referencing a property of the Maven Project Object Model (POM). Specifically, you are referencing a property of the org.apache.maven.model.Model class which is being exposed as the implicit variable project. When you reference a property using this implicit variable, you are using simple dot notation to reference a bean property of the Model object. For example, when you reference ${project.version}, you are really invoking the getVersion() method on the instance of Model that is being exposed as project.The POM is also represented in the pom.xml document present in all Maven projects. Anything in a Maven POM can be referenced with a property. The following list shows some common property references from the Maven project.

The directory that the current project resides in, represented as an URI. Since Maven 2.1.0

http://maven.apache.org/ref/2.2.1/mavenmodel/maven.html* For a full list of properties available on the Maven Model object, take a look at the JavaDoc for the maven-model project here http://maven.apache.org/ref/2.2.1/maven-model/apidocs/index.html

You can also reference any properties in the Maven Local Settings file which is usually stored in ~/.m2/settings.xml. This file contains user-specific configuration such as the location of the local repository and any servers, profiles, and

A full reference for the Local Settings file and corresponding properties is available here http://maven.apache.org/ref/2.2.1/mavensettings/settings.html

Contains the current PATH in which Maven is running. The PATH contains a list of directories used to locate executable scriptsand programs.(On *nix systems) this variable points to a user's home directory. Instead of referencing this, you should use the ${user.home}Contains the Java installation directory. This can point to either a Java Development Kit (JDK) installation or a Java RuntimeEnvironment (JRE). Instead of using this, you should consider referencing the ${java.home} property.

While they are available, you should always use the Java System properties if you have the choice. If you need a user's home directory use ${user.home} instead of ${env.HOME}. If you do this, you'll end up with a more portable build that is more likely to adhere to the Write-Once-Run-Anywhere (WORA) promise of the Java platform.

Maven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() you can reference in a Maven property. The following table lists available properties:

DescriptionJava Virtual Machine specification versionJava Virtual Machine specification vendorJava vendor URLJava installation directoryJava Virtual Machine specification versionJava Virtual Machine specification vendorJava Virtual Machine specification nameJava Virtual Machine implementation versionJava Virtual Machine implementation vendorJava Virtual Machine implementation nameJava Runtime Environment specification versionJava Runtime Environment specification vendorJava Runtime Environment specification nameJava class format version numberJava class pathPath of extension directory or directoriesOperating system nameOperating system architectureOperating system versionFile separator ("/" on UNIX, "\" on Windows)Path separator (":" on UNIX, ";" on Windows)Line separator ("\n" on UNIX and Windows)User's account nameUser's home directoryUser's current working

you have the ability to define your own arbitrary properties. Properties can be defined in a POM or in a Profile. The properties set in a POM or in a Maven Profile can be referenced just like any other property available throughout Maven. User-defined properties can be referenced in a POM, or they can be used to filter resources via the Maven Resource plugin.

<project> ... <properties> <mavenVersion>2.1</mavenVersion> </properties> <dependencies> <dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-artifact</artifactId> <version>${mavenVersion}</version> </dependency> <dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-project</artifactId> <version>${mavenVersion}</version> </dependency> </dependencies> ...</project>

Environment variables can be referenced with the env.* prefix. Some interesting environment variables are listed in the following list:

You can use Maven properties in a pom.xml file or in any resource that is being processed by the Maven Resource plugin's filtering features. A property is always surrounded by ${ and }. For example, to reference the project.version

>> Any property which can be retrieved from the System.getProperty() method can be referenced as a Maven property.

In addition to the implicit properties listed above, a Maven POM, Maven Settings, or a Maven Profile can define a set of arbitrary, user-defined properties. The following sections provide some detail on the various properties available in a

When a Maven Project Property is referenced, the property name is referencing a property of the Maven Project Object Model (POM). Specifically, you are referencing a property of the org.apache.maven.model.Model class which is being exposed as the implicit variable project. When you reference a property using this implicit variable, you are using simple dot notation to reference a bean property of the Model object. For example, when you reference ${project.version},

The POM is also represented in the pom.xml document present in all Maven projects. Anything in a Maven POM can be referenced with a property. The following list shows some common property references from the Maven project.

* The format of the build timestamp can be customized by declaring the property maven.build.timestamp.format as shown in the example below:

<project> ... <properties> <maven.build.timestamp.format>yyyyMMdd-HHmm</maven.build.timestamp.format> </properties> ...</project>

The format pattern has to comply with the rules given in the API documentation for SimpleDateFormat. If the property is not present, the format defaults to the value already given in the example.

http://maven.apache.org/ref/2.2.1/maven-model/apidocs/index.html

You can also reference any properties in the Maven Local Settings file which is usually stored in ~/.m2/settings.xml. This file contains user-specific configuration such as the location of the local repository and any servers, profiles, and

http://maven.apache.org/ref/2.2.1/mavensettings/settings.html

While they are available, you should always use the Java System properties if you have the choice. If you need a user's home directory use ${user.home} instead of ${env.HOME}. If you do this, you'll end up with a more portable build

Maven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() you can reference in a Maven property. The following table lists available properties:

you have the ability to define your own arbitrary properties. Properties can be defined in a POM or in a Profile. The properties set in a POM or in a Maven Profile can be referenced just like any other property available throughout Maven.

<project>... <profiles> <profile> <id>some-profile</id> <properties> <arbitrary.property>This is some text</arbitrary.property> </properties> </profile> </profiles>...</project>

Resource Filtering

SAMPLE 1src/main/resources/applicationContext.xml

SAMPLE 2src/main/command/run.bat

You can use Maven to perform variable replacement on project resources. When resource filtering is activated, Maven will scan resources for property references surrounded by ${ and }. When it finds these references it will replace them with the appropriate value in much the same way the properties defined in the previous section can be referenced from a POM. This feature is especially helpful when you need to parameterize a build with different configuration values depending on the target deployment platform.Using Maven resource filtering you can reference Maven properties and then use Maven profiles to define different configuration values for different target deployment environments.Resource filtering is disabled by default to prevent any unintentional resource filtering. To turn on resource filtering, you need to use the resources child element of the build element in a POM.

<beans xmlns="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<bean id="someDao" class="com.example.SomeDao"> <property name="dataSource" ref="dataSource"/> </bean> <bean id="dataSource" destroy-method="close"class="org.apache.commons.dbcp.BasicDataSource"> <property name="driverClassName" value="${jdbc.driverClassName}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean></beans>

* This program would read this file at runtime, and your build is going to replace the references to properties like jdbc.url and jdbc.username with the values you defined in the pom.xml

SAMPLE 3src/main/resources/service.xml

src/main/filters/default.properties

Configuring Additional Resource Directories

@echo offjava -jar ${project.build.finalName}.jar %*

The process-resources phase "processes" resources and copies them to the output directory. In addition to copying the resources to the output directory, Maven can also apply a filter to the resources that allows you to replace tokens within resource file. Just like variables are referenced in a POM using ${...} notation, you can reference variables in your project's resources using the same syntax.

<service>  <url>${jdbc.url}</url> <user>${jdbc.username}</user> <password>${jdbc.password}</password></service>

jdbc.url=jdbc:hsqldb:mem:mydbjdbc.username=sajdbc.password=

As with all directories in Maven, the resources directory does not need to be in src/main/resources. This is just the default value defined in the Super POM. You should also note that you don't need to consolidate all of your resources into a single directory. You can always separate resources into separate directories under src/main. Assume that you have a project which contains hundreds of XML documents and hundreds of images. Instead of mixing the resources in the src/main/resources directory, you might want to create two directories src/main/xml and src/main/images to hold this content. To add directories to the list of resource directories, you would add the following resource elements to your build configuration.

<build>... <resources> <resource> <directory>src/main/resources</directory> </resource> <resource> <directory>src/main/xml</directory> </resource> <resource> <directory>src/main/images</directory> </resource> </resources>...</build>

pom.xml

pom.xml

You can use Maven to perform variable replacement on project resources. When resource filtering is activated, Maven will scan resources for property references surrounded by ${ and }. When it finds these references it will replace them with the appropriate value in much the same way the properties defined in the previous section can be referenced from a POM. This feature is especially helpful when you need to parameterize a build with different configuration values depending on the target

Using Maven resource filtering you can reference Maven properties and then use Maven profiles to define different configuration values for different target deployment environments.to prevent any unintentional resource filtering. To turn on resource filtering, you need to use the resources child element of the build element in a POM.

<project>... <properties> <jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName> <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url> <jdbc.username>dev_user</jdbc.username> <jdbc.password>s3cr3tw0rd</jdbc.password> </properties>... <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>... <profiles> <profile> <id>production</id> <properties> <jdbc.driverClassName>oracle.jdbc.driver.OracleDriver</jdbc.driverClassName> <jdbc.url>jdbc:oracle:thin:@proddb01:1521:PROD</jdbc.url> <jdbc.username>prod_user</jdbc.username> <jdbc.password>s00p3rs3cr3t</jdbc.password> </properties> </profile> </profiles></project>

* This example also defines a production profile under the profiles/profile element which overrides the default properties with values that would be appropriate for a production environment. In this particular POM, the default values for the database connection are for a local MySQL database installed on a developer's machine. When the project is built with the production profile activated, Maven will configure the system to connect to a production Oracle database using a different driver class, URL, username, and password.

pom.xml

<build> <groupId>org.sonatype.mavenbook</groupId> <artifactId>simple-cmd</artifactId> <version>2.3.1</version>... <resources> <resource> <filtering>true</filtering> <directory>${basedir}/src/main/command</directory> <includes> <include>run.bat</include> <include>run.sh</include> </includes> <targetPath>${basedir}</targetPath> </resource> <resource> <directory>${basedir}/src/main/resources</directory> </resource></resources>...</build>

* This example shows you how to declare two resource directories and supply them with different filtering and target directory preferences

The process-resources phase "processes" resources and copies them to the output directory. In addition to copying the resources to the output directory, Maven can also apply a filter to the resources that allows you to replace tokens within resource file. Just like variables are referenced in a POM using ${...} notation, you can reference variables in your project's resources using the same syntax.

<build> <filters> <filter>src/main/filters/default.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources></build>

* To configure resource filtering with this default.properties file, we need to specify two things in a project's POM: a list of properties files in the filters element of the build configuration, and a flag to Maven that the resources directory is to be filtered.

As with all directories in Maven, the resources directory does not need to be in src/main/resources. This is just the default value defined in the Super POM. You should also note that you don't need to consolidate all of your resources into a single directory. You can always separate resources into separate directories under src/main. Assume that you have a project which contains hundreds of XML documents and hundreds of images. Instead of mixing the resources in the src/main/resources directory, you might want to create two directories src/main/xml and src/main/images to hold this content. To add directories to the list of resource directories, you would add the following resource elements to your build configuration.

Results

Results

You can use Maven to perform variable replacement on project resources. When resource filtering is activated, Maven will scan resources for property references surrounded by ${ and }. When it finds these references it will replace them with the appropriate value in much the same way the properties defined in the previous section can be referenced from a POM. This feature is especially helpful when you need to parameterize a build with different configuration values depending on the target

Using Maven resource filtering you can reference Maven properties and then use Maven profiles to define different configuration values for different target deployment environments.to prevent any unintentional resource filtering. To turn on resource filtering, you need to use the resources child element of the build element in a POM.

$ mvn install...$ cat target/classes/applicationContext.xml...<bean id="dataSource" destroy-method="close"class="org.apache.commons.dbcp.BasicDataSource"><property name="driverClassName" value="com.mysql.jdbc.Driver"/><property name="url" value="jdbc:mysql://localhost:3306/development_db"/><property name="username" value="dev_user"/><property name="password" value="s3cr3tw0rd"/></bean>...

$ mvn -Pproduction install...$ cat target/classes/applicationContext.xml...<bean id="dataSource" destroy-method="close"class="org.apache.commons.dbcp.BasicDataSource"><property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/><property name="url" value="jdbc:oracle:thin:@proddb01:1521:PROD"/><property name="username" value="prod_user"/><property name="password" value="s00p3rs3cr3t"/></bean>...

Results

$ mvn process-resources...$ cat target/classes/run.bat…@echo offjava -jar simple-cmd-2.3.1.jar %*

The process-resources phase "processes" resources and copies them to the output directory. In addition to copying the resources to the output directory, Maven can also apply a filter to the resources that allows you to replace tokens within resource

$ mvn install...$ cat target/classes/service.xml...<service>  <url>jdbc:hsqldb:mem:mydb</url> <user>sa</user> <password></password></service>...

This is just the default value defined in the Super POM. You should also note that you don't need to consolidate all of your resources into a single directory. You can always separate resources into separate directories under src/main. Assume that you have a project which contains hundreds of XML documents and hundreds of images. Instead of mixing the resources in the src/main/resources directory, you might want to create two directories src/main/xml and src/main/images to hold this content. To add directories to the list of resource directories, you would add the following resource elements to your build configuration.

mvn useful commands

Displaying Version Information

Getting Help

The effective POM

List active profiles

Describing a Maven Plugin

Skip tests altogether

To execute mvn install under the production profile

Listing Active Profiles

To excecute a maven plugin

To excecute a file

To check whether a profile is active for a given build

$ mvn -v

$ mvn --help

$ mvn help:effective-pom

$ mvn help:active-profiles

$ mvn help:describe -Dcmd=compiler:compile

$ mvn help:describe -Dcmd=compiler:compile -Ddetail

$ mvn help:describe -Dplugin=help

$ mvn help:describe -Dplugin=help -Dfull

$ mvn help:describe -Dplugin=compiler

$ mvn help:describe -Dplugin=install

$ mvn help:describe -Dplugin=compiler -Dmojo=compile -Dfull

$ mvn help:describe -Dplugin=org.apache.maven.plugins:maven-compiler-plugin

$ mvn install -Dmaven.test.skip=true

$ mvn install -DskipTests=true

$ mvn clean install -Pproduction -X

$ mvn help:active-profiles

$ mvn install -Denvironment.type=dev

$ mvn install -Denvironment.type=prod

$mvn -e install -f auditpom.xml

$ mvn groupId:artifactId:version:goal

mvn --help

usage: mvn [options] [<goal(s)>] [<phase(s)>]

Options:

-am,--also-make -amd,--also-make-dependents -B,--batch-mode -c,--lax-checksums -C,--strict-checksums -cpu,--check-plugin-updates -D,--define <arg> -e,--errors -emp,--encrypt-master-password <arg> -ep,--encrypt-password <arg> -f,--file -fae,--fail-at-end -ff,--fail-fast -fn,--fail-never -gs,--global-settings <arg> -h,--help -N,--non-recursive -npr,--no-plugin-registry -npu,--no-plugin-updates -o,--offline -P,--activate-profiles <arg> -pl,--projects <arg> -q,--quiet -r,--reactor -rf,--resume-from <arg> -s,--settings <arg> -U,--update-snapshots -up,--update-plugins -v,--version -V,--show-version -X,--debug

Options:

If project list is specified, also build projects required by the listIf project list is specified, also build projects that depend on projects on the listRun in non-interactive (batch) modeWarn if checksums don't matchFail the build if checksums don't matchForce upToDate check for any relevant registered pluginsDefine a system propertyProduce execution error messagesEncrypt master security passwordEncrypt server passwordForce the use of an alternate POM fileOnly fail the build afterwards; allow all non-impacted builds to continueStop at first failure in reactorized buildsNEVER fail the build, regardless of project resultAlternate path for the global settings fileDisplay help informationDo not recurse into sub-projectsDon't use ~/.m2/plugin-registry.xml for plugin versionsSuppress upToDate check for any relevant registered pluginsWork offlineComma-delimited list of profiles to activateBuild specified reactor projects instead of all projectsQuiet output - only show errorsDynamically build reactor from subdirectoriesResume reactor from specified projectAlternate path for the user settings fileForces a check for updated releases and snapshots on remote repositoriesSynonym for cpuDisplay version informationDisplay version information WITHOUT stopping buildProduce execution debug output

MAVEN TIPS

To prevent: "[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!"

To set up Maven so it will compile with a target and source JVM of my choice

To include tools.jar in my dependencies

Disabling Maven Meta Information

<project> ... <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> ...</project>

... <build> ... <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> ... </build> ...

... <profiles> <profile> <id>default-tools.jar</id> <activation> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <version>1.4.2</version> <scope>system</scope> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> </profile> </profiles> ...

To add plugin's goals to phases in your project.

Minimal POM

What is a Mojo?

Maven is configured to look for plugins in two groups:

Maven Standard Directory Layoutsrcsrc/main/javasrc/main/resourcessrc/main/filterssrc/main/assemblysrc/main/configsrc/main/webapp

<project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.1-alpha-1</version> <configuration> <archive> <addMavenDescriptor>false</addMavenDescriptor> </archive> </configuration> </plugin> </plugins> </build> ...</project>

... <plugin> <groupId>com.mycompany.example</groupId> <artifactId>display-maven-plugin</artifactId> <version>1.0</version> <executions> <execution> <phase>process-test-resources</phase> <configuration> <models> <model>src/main/xyz/file.txt</model> </models> <version>4.0.0</version> </configuration> <goals> <goal>time</goal> </goals> </execution> </executions> </plugin>...

<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1.0.0</version></project>

A mojo is a Maven plain Old Java Object. Each mojo is an executable goal in Maven, and a plugin is a distribution of one or more related mojos.

org.apache.maven.plugins (core Maven plugins)org.codehaus.mojo (extra plugins)

src/test/javasrc/test/resourcessrc/test/filterssrc/sitetargetLICENSE.txtNOTICE.txtREADME.txtYou can always separate resources into separate directories under src/main

To change the default behavior of the SureFire plugin (Produce output instead of stopping a build whenever a unit test failure is encountered)

To install an artifact into the local repository

<build>...<resources><resource><directory>src/main/resources</directory></resource><resource><directory>src/main/xml</directory></resource><resource><directory>src/main/images</directory></resource></resources>...</build>

<build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId><configuration><testFailureIgnore>true</testFailureIgnore></configuration></plugin>...</plugins></build>

mvn install:install-file -Dfile=commons-lang-2.1.0.jar -DgroupId=swh-libs.p2g.commons-jars -DartifactId=commons-lang -Dversion=2.1.0 -Dpackaging=jar -DgeneratePom=true

To prevent: "[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!"

To set up Maven so it will compile with a target and source JVM of my choice

To include tools.jar in my dependencies

Disabling Maven Meta Information

To add plugin's goals to phases in your project.

Minimal POM

What is a Mojo?

Maven is configured to look for plugins in two groups:

Maven Standard Directory LayoutDirectory contains all of the source material for building the project, its site and so onApplication/Library sourcesApplication/Library resourcesResource filter filesAssembly descriptorsConfiguration filesWeb application sources

Many Java archive generating plugins accept the archive configuration element to customise the generation of the archive. In the standard Maven Plugins, this includes the jar, war, ejb, ear and assembly plugins.

By default, Maven generated archives include the META-INF/maven directory, which contains the pom.xml file used to build the archive, and a pom.properties file that includes some basic properties in a small, easier to read format.

To disable the generation of these files, include the following configuration for your plugin (in this example, the WAR plugin is used)

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.plugins can contain information that indicates which lifecycle phase to bind a goal to. 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.The goals that are configured will be added to the goals already bound to the lifecycle from the packaging selected. 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. Note that you can use the <executions> element to gain more control over the order of particular goals.You might be wondering why that <executions> element is there. That is so that you can run the same goal multiple times with different configuration if needed. Separate executions can also be given an ID so that during inheritance or the application of profiles you can control whether goal configuration is merged or turned into an additional execution.When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.

Test sourcesTest resourcesTest resource filter filesSitedirectory is used to house all output of the buildProject's licenseNotices and attributions required by libraries that the project depends onProject's readme

You can always separate resources into separate directories under src/main

To change the default behavior of the SureFire plugin (Produce output instead of stopping a build whenever a unit test failure is encountered)

To install an artifact into the local repository

Directory contains all of the source material for building the project, its site and so on

Project Hierarchy

projectThe <project> element is the root of the descriptor. The following table lists all of the possible child elements.

Element TypemodelVersion String

parent Parent

groupId String

artifactId String

version String

packaging String

name String

description String

url String

inceptionYear String

organization Organization

licenses/license* List<License>

mailingLists/mailingList* List<MailingList>developers/developer* List<Developer>contributors/contributor* List<Contributor>issueManagement IssueManagementscm ScmciManagement CiManagementprerequisites Prerequisitesbuild Buildprofiles/profile* List<Profile>

distributionManagement

modules/module* List<String>

repositories/repository* List<Repository>pluginRepositories/pluginRepository* List<Repository>

dependencies/dependency* List<Dependency>

reports DOM

reporting Reporting

dependencyManagement

Properties

parentThe <parent> element contains informations required to the parent project.

DistributionManagement

DependencyManagement

properties/key=value*

Element TypeartifactId StringgroupId Stringversion String

relativePath String

organizationSpecifies the organization that produces this project.

Element Typename Stringurl String

licenseDescribes the licenses for this project. This is used to generate the license page of the project's web site, as well as being taken into consideration in other reporting and validation. The licenses listed for the project are that of the project itself, and not of dependencies.

Element Typename Stringurl String

distribution String

comments String

mailingListThis element describes all of the mailing lists associated with a project. The auto-generated site references this information.

Element Typename String

subscribe String

unsubscribe String

post String

archive StringotherArchives/otherArchive* List<String>

developerInformation about one of the committers on this project.

Element Typeid Stringname Stringemail Stringurl Stringorganization StringorganizationUrl String

roles/role* List<String>

timezone StringPropertiesproperties/key=value*

contributorDescription of a person who has contributed to the project, but who does not have commit privileges. Usually, these contributions come in the form of patches submitted.

Element Typename Stringemail Stringurl Stringorganization StringorganizationUrl String

roles/role* List<String>

timezone StringProperties

issueManagementInformation about the issue tracking (or bug tracking) system used to manage this project.

Element Typesystem Stringurl String

scm

The <scm> element contains informations required to the SCM (Source Control Management) of the project.

Element Type

connection String

developerConnection String

tag String

url String

ciManagementThe <CiManagement> element contains informations required to the continuous integration system of the project.

Element Typesystem Stringurl Stringnotifiers/notifier* List<Notifier>

notifierConfigures one method for notifying users/developers when a build breaks.

Element Type

type String

sendOnError boolean

sendOnFailure boolean

sendOnSuccess boolean

sendOnWarning boolean

address StringProperties

prerequisites

Describes the prerequisites a project can have.


configuration/key=value*

Element Type

maven String

buildThe <build> element contains informations required to build the project.

Element Type

sourceDirectory String

scriptSourceDirectory String

testSourceDirectory String

outputDirectory StringtestOutputDirectory Stringextensions/extension* List<Extension>defaultGoal String

resources/resource* List<Resource>

testResources/testResource* List<Resource>directory String

finalName String

filters/filter* List<String>

pluginManagement PluginManagement

plugins/plugin* List<Plugin>

extensionDescribes a build extension to utilise.

Element TypegroupId StringartifactId Stringversion String

resourceThis element describes all of the classpath resources associated with a project or unit tests.

Element Type

targetPath String

filtering boolean

mergeId String

directory Stringincludes/include* List<String>excludes/exclude* List<String>

testResourceThis element describes all of the classpath resources associated with a project or unit tests.

Element Type

targetPath String

filtering boolean

mergeId String

directory Stringincludes/include* List<String>excludes/exclude* List<String>

pluginManagementSection for management of default plugin information for use in a group of POMs.

Element Typeplugins/plugin* List<Plugin>

pluginThe <plugin> element contains informations required for a plugin.

Element TypegroupId String

artifactId Stringversion String

extensions boolean

executions/execution* List<PluginExecution>dependencies/dependency* List<Dependency>goals DOMinherited Stringconfiguration DOM

executionThe <execution> element contains informations required for the execution of a plugin.

Element Type

id String

phase String

goals/goal* List<String>inherited Stringconfiguration DOM

dependencyThe <dependency> element contains information about a dependency of the project.

Element TypegroupId StringartifactId Stringversion String

type String

classifier String

scope String

systemPath String

exclusions/exclusion* List<Exclusion>

optional boolean

exclusionThe <exclusion> element contains informations required to exclude an artifact to the project.

Element TypeartifactId StringgroupId String

profileModifications to the build process which is activated based on environmental parameters or command line arguments.

Element Typeid Stringactivation Activationbuild BuildBase

distributionManagement

modules/module* List<String>

repositories/repository* List<Repository>pluginRepositories/pluginRepository* List<Repository>


reports DOM

reporting Reporting

dependencyManagement

Properties

activationThe conditions within the build runtime environment which will trigger the automatic inclusion of the build profile.

Element Type

activeByDefault boolean

jdk String

os ActivationOS

DistributionManagement

DependencyManagement


property ActivationPropertyfile ActivationFile

osThis is an activator which will detect an operating system's attributes in order to activate its profile.

Element Type

name String

family Stringarch Stringversion String

propertyThis is the property specification used to activate a profile. If the value field is empty, then the existence of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well.

Element Typename Stringvalue String

fileThis is the file specification used to activate the profile. The missing value will be the location of a file that needs to exist, and if it doesn't the profile will be activated. On the other hand exists will test for the existence of the file and if it is there the profile will be activated.

Element Typemissing Stringexists String

distributionManagementThis elements describes all that pertains to distribution for a project. It is primarily used for deployment of artifacts and the site produced by the build.

Element Typerepository DeploymentRepositorysnapshotRepository DeploymentRepositorysite Site

downloadUrl String

relocation Relocation

status String

repositoryRepository contains the information needed for deploying to the remote repository.

Element Type

uniqueVersion boolean

id String

name Stringurl String

layout String

snapshotRepositoryRepository contains the information needed for deploying to the remote repository.

Element Type

uniqueVersion boolean

id String


layout String

site

Contains the information needed for deploying websites.

Element Typeid Stringname Stringurl String

relocationDescribes where an artifact has moved to. If any of the values are omitted, it is assumed to be the same as it was before.

Element TypegroupId StringartifactId Stringversion Stringmessage String

pluginRepositoryA repository contains the information needed for establishing connections with remote repository.

Element Typereleases RepositoryPolicysnapshots RepositoryPolicy

id String


layout String

releasesDownload policy.

Element Type

enabled boolean

updatePolicy StringchecksumPolicy String

snapshotsDownload policy.

Element Type

enabled boolean

updatePolicy StringchecksumPolicy String

reportingSection for management of reports and their configuration.

Element TypeexcludeDefaults Boolean

outputDirectory Stringplugins/plugin* List<ReportPlugin>

dependencyManagementSection for management of default dependency information for use in a group of POMs.

Element Type


The <project> element is the root of the descriptor. The following table lists all of the possible child elements.

DescriptionDeclares to which version of project descriptor this POM conforms.

The current version of the artifact produced by this project.

The full name of the project.

The URL to the project's homepage.

The project's issue management system information.Specification for the SCM used by the project, such as CVS, Subversion, etc.The project's continuous integration information.Describes the prerequisites in the build environment for this project.Information required to build the project.

The location of the parent project, if one exists. Values from the parent project will be the default for this project if they are left unspecified. The location is given as a group ID, artifact ID and version.A universally unique identifier for a project. It is normal to use a fully-qualified package name to distinguish it from other projects with a similar name (eg. org.apache.maven).

The identifier for this artifact that is unique within the group given by the group ID. An artifact is something that is either produced or used by a project. Examples of artifacts produced by Maven for a project include: JARs, source and binary distributions, and WARs.

The type of artifact this project produces, for example jarwarearpom. Plugins can create their own packaging, and therefore their own packaging types, so this list does not contain all possible types.Default value is: jar.

A detailed description of the project, used by Maven whenever it needs to describe the project, such as on the web site. While this element can be specified as CDATA to enable the use of HTML tags within the description, it is discouraged to allow plain text representation. If you need to modify the index page of the generated web site, you are able to specify your own instead of adjusting this text.

The year of the project's inception, specified with 4 digits. This value is used when generating copyright notices as well as being informational.

This element describes various attributes of the organization to which the project belongs. These attributes are utilized when documentation is created (for copyright notices and links).

(Many) This element describes all of the licenses for this project. Each license is described by a license element, which is then described by additional elements. Projects should only list the license(s) that applies to the project and not the licenses that apply to dependencies. If multiple licenses are listed, it is assumed that the user can select any of them, not that they must accept all.

(Many) Contains information about a project's mailing lists.(Many) Describes the committers of a project.(Many) Describes the contributors to a project that are not yet committers.

(Many) A listing of project-local build profiles which will modify the build process when activated.Distribution information for a project that enables deployment of the site and artifacts to remote web servers and repositories respectively.(Many) 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.(Many) The lists of the remote repositories for discovering dependencies and extensions.(Many) The lists of the remote repositories for discovering plugins for builds and reports.

(Many) 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.

Deprecated. Now ignored by Maven.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.

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.

(Many) 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>.

DescriptionThe artifact id of the parent project to inherit from.The group id of the parent project to inherit from.The version of the parent project to inherit.

DescriptionThe full name of the organization.The URL to the organization's home page.

Describes the licenses for this project. This is used to generate the license page of the project's web site, as well as being taken into consideration in other reporting and validation. The licenses listed for the project are that of the project itself, and not of dependencies.

DescriptionThe full legal name of the license.The official url for the license text.The primary method by which this project may be distributed.repomay be downloaded from the Maven repositorymanualuser must manually download and install the dependency.Addendum information pertaining to this license.

This element describes all of the mailing lists associated with a project. The auto-generated site references this information.

DescriptionThe name of the mailing list.

The link to a URL where you can browse the mailing list archive.

DescriptionThe unique ID of the developer in the SCM.The full name of the contributor.The email address of the contributor.The URL for the homepage of the contributor.The organization to which the contributor belongs.The URL of the organization.

The timezone the contributor is in. This is a number in the range -11 to 12.

The relative path of the parent pom.xml file within the check out. The default value is ../pom.xml. Maven looks for the parent pom first in the reactor of currently building projects, then in this location on the filesystem, then the local repository, and lastly in the remote repo. relativePath allows you to select a different location, for example when your structure is flat, or deeper without an intermediate parent pom. However, the group ID, artifact ID and version are still required, and must match the file in the location given or it will revert to the repository for the POM. This feature is only for enhancing the development in a local checkout of that project.

Default value is: ../pom.xml.

The email address or link that can be used to subscribe to the mailing list. If this is an email address, a mailto: link will automatically be created when the documentation is created.The email address or link that can be used to unsubscribe to the mailing list. If this is an email address, a mailto: link will automatically be created when the documentation is created.

The email address or link that can be used to post to the mailing list. If this is an email address, a mailto: link will automatically be created when the documentation is created.

(Many) The link to alternate URLs where you can browse the list archive.

(Many) The roles the contributor plays in the project. Each role is described by a role element, the body of which is a role name. This can also be used to describe the contribution.

(Many) Properties about the contributor, such as an instant messenger handle.

Description of a person who has contributed to the project, but who does not have commit privileges. Usually, these contributions come in the form of patches submitted.

DescriptionThe full name of the contributor.The email address of the contributor.The URL for the homepage of the contributor.The organization to which the contributor belongs.The URL of the organization.

The timezone the contributor is in. This is a number in the range -11 to 12.

DescriptionThe name of the issue management system, e.g. BugzillaURL for the issue management system used by the project.

The <scm> element contains informations required to the SCM (Source Control Management) of the project.

Description

Just like connection, but for developers, i.e. this scm connection will not be read only.The tag of current code. By default, it's set to HEAD during development.

The URL to the project's browsable SCM repository, such as ViewVC or Fisheye.

The <CiManagement> element contains informations required to the continuous integration system of the project.

DescriptionThe name of the continuous integration system, e.g. continuum.URL for the continuous integration system used by the project if it has a web interface.

DescriptionThe mechanism used to deliver notifications.

Whether to send notifications on error.

Whether to send notifications on failure.

Whether to send notifications on success.

Whether to send notifications on warning.

(Many) The roles the contributor plays in the project. Each role is described by a role element, the body of which is a role name. This can also be used to describe the contribution.

(Many) Properties about the contributor, such as an instant messenger handle.

The source control management system URL that describes the repository and how to connect to the repository. For more information, see the URL format and list of supported SCMs. This connection is read-only.

Default value is: HEAD.

(Many) Configuration for notifying developers/users when a build is unsuccessful, including user information and notification mode.

Default value is: mail.

Default value is: true.



Default value is: true.Deprecated. Where to send the notification to - eg email address.(Many) Extended configuration specific to this notifier goes here.

DescriptionThe minimum version of Maven required to build the project, or to use this plugin.

Description

The directory where compiled application classes are placed.The directory where compiled test classes are placed.

The default goal (or phase in Maven 2) to execute when none is specified for the project.

The directory where all files generated by the build are placed.

DescriptionThe group ID of the extension's artifact.The artifact ID of the extension.The version of the extension.

Description

Describe the directory where the resources are stored. The path is relative to the POM.

Default value is: 2.0.

This element specifies a directory containing the source of the project. The generated build system will compile the source in this directory when the project is built. The path given is relative to the project descriptor.

This element specifies a directory containing the script sources of the project. This directory is meant to be different from the sourceDirectory, in that its contents will be copied to the output directory in most cases (since scripts are interpreted rather than compiled).

This element specifies a directory containing the unit test source of the project. The generated build system will compile these directories when the project is being tested. The path given is relative to the project descriptor.

(Many) A set of build extensions to use from this project.

(Many) This element describes all of the classpath resources such as properties files associated with a project. These resources are often included in the final package.(Many) This element describes all of the classpath resources such as properties files associated with a project's unit tests.

The filename (excluding the extension, and with no path information) that the produced artifact will be called. The default value is ${artifactId}-${version}.(Many) The list of filter properties files that are used when filtering is enabled.

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.

(Many) The list of plugins to use.

Describe the resource target path. The path is relative to the target/classes directory (i.e. ${project.build.outputDirectory}). For example, if you want that resource to appear in a specific package (org.apache.maven.messages), you must specify this element with this value: org/apache/maven/messages. This is not required if you simply put the resources in that directory structure at the source, however.

Whether resources are filtered to replace tokens with parameterised values or not. The values are taken from the properties element and from the properties in the files listed in the filters element.Default value is: false.

FOR INTERNAL USE ONLY. This is a unique identifier assigned to each resource to allow Maven to merge changes to this resource that take place during the execution of a plugin. This field must be managed by the generated parser and formatter classes in order to allow it to survive model interpolation.

(Many) A list of patterns to include, e.g. **/*.xml.(Many) A list of patterns to exclude, e.g. **/*.xml

Description

Describe the directory where the resources are stored. The path is relative to the POM.

Description

DescriptionThe group ID of the plugin in the repository.

The artifact ID of the plugin in the repository.The version (or valid range of versions) of the plugin to be used.

Whether any configuration should be propagated to child POMs.The configuration as DOM object.

Description

Whether any configuration should be propagated to child POMs.The configuration as DOM object.

DescriptionThe project group that produced the dependency, e.g. org.apache.maven.The unique id for an artifact produced by the project group, e.g. maven-artifact.The version of the dependency, e.g. 3.2.1. In Maven 2, this can also be specified as a range of versions.

Describe the resource target path. The path is relative to the target/classes directory (i.e. ${project.build.outputDirectory}). For example, if you want that resource to appear in a specific package (org.apache.maven.messages), you must specify this element with this value: org/apache/maven/messages. This is not required if you simply put the resources in that directory structure at the source, however.

Whether resources are filtered to replace tokens with parameterised values or not. The values are taken from the properties element and from the properties in the files listed in the filters element.Default value is: false.

FOR INTERNAL USE ONLY. This is a unique identifier assigned to each resource to allow Maven to merge changes to this resource that take place during the execution of a plugin. This field must be managed by the generated parser and formatter classes in order to allow it to survive model interpolation.

(Many) A list of patterns to include, e.g. **/*.xml.(Many) A list of patterns to exclude, e.g. **/*.xml

(Many) The list of plugins to use.

Default value is: org.apache.maven.plugins.

Whether to load Maven extensions (such as packaging and type handlers) from this plugin. For performance reasons, this should only be enabled when necessary.Default value is: false.(Many) Multiple specifications of a set of goals to execute during the build lifecycle, each having (possibly) a different configuration.(Many) Additional dependencies that this project needs to introduce to the plugin's classloader.Deprecated. Unused by Maven.

The identifier of this execution for labelling the goals during the build, and for matching executions to merge during inheritance and profile injection.Default value is: default.The build lifecycle phase to bind the goals in this execution to. If omitted, the goals will be bound to the default phase specified in their metadata.(Many) The goals to execute with the given configuration.

DescriptionThe artifact ID of the project to exclude.The group ID of the project to exclude.

Modifications to the build process which is activated based on environmental parameters or command line arguments.

DescriptionThe identifier of this build profile. This is used for command line activation, and identifies profiles to be merged.The conditional logic which will automatically trigger the inclusion of this profile.Information required to build the project.

The conditions within the build runtime environment which will trigger the automatic inclusion of the build profile.

Description

Specifies that this profile will be activated when matching operating system attributes are detected.

The type of dependency. This defaults to jar. While it usually represents the extension on the filename of the dependency, that is not always the case. A type can be mapped to a different extension and a classifier. The type often correspongs to the packaging used, though this is also not always the case. Some examples are jar, war, ejb-client and test-jar. New types can be defined by plugins that set extensions to true, so this is not a complete list.

Default value is: jar.The classifier of the dependency. This allows distinguishing two artifacts that belong to the same POM but were built differently, and is appended to the filename after the version. For example, jdk14 and jdk15.

The scope of the dependency - compile, runtime, test, system, and provided. Used to calculate the various classpaths used for compilation, testing, and so on. It also assists in determining which artifacts to include in a distribution of this project. For more information, see the dependency mechanism.

FOR SYSTEM SCOPE ONLY. Note that use of this property is discouraged and may be replaced in later versions. This specifies the path on the filesystem for this dependency. Requires an absolute path for the value, not relative. Use a property that gives the machine specific absolute path, e.g. ${java.home}.

(Many) Lists a set of artifacts that should be excluded from this dependency's artifact list when it comes to calculating transitive dependencies.Indicates the dependency is optional for use of this library. While the version of the dependency will be taken into account for dependency calculation if the library is used elsewhere, it will not be passed on transitively.Default value is: false.

Distribution information for a project that enables deployment of the site and artifacts to remote web servers and repositories respectively.

(Many) 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.(Many) The lists of the remote repositories for discovering dependencies and extensions.(Many) The lists of the remote repositories for discovering plugins for builds and reports.

(Many) 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.

Deprecated. Now ignored by Maven.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.

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.

(Many) 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>.

If set to true, this profile will be active unless another profile in this pom is activated using the command line -P option or by one of that profile's activators.Default value is: false.Specifies that this profile will be activated when a matching JDK is detected. For example, 1.4 only activates on JDKs versioned 1.4, while !1.4 matches any JDK that is not version 1.4.

Specifies that this profile will be activated when this system property is specified.Specifies that this profile will be activated based on existence of a file.

Description

The general family of the OS to be used to activate the profile, such as windows or unix.The architecture of the operating system to be used to activate the profile.The version of the operating system to be used to activate the profile.

This is the property specification used to activate a profile. If the value field is empty, then the existence of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well.

DescriptionThe name of the property to be used to activate a profile.The value of the property required to activate a profile.

This is the file specification used to activate the profile. The missing value will be the location of a file that needs to exist, and if it doesn't the profile will be activated. On the other hand exists will test for the existence of the file and if it is there the profile will be activated.

DescriptionThe name of the file that must be missing to activate the profile.The name of the file that must exist to activate the profile.

This elements describes all that pertains to distribution for a project. It is primarily used for deployment of artifacts and the site produced by the build.

DescriptionInformation needed to deploy the artifacts generated by the project to a remote repository.Where to deploy snapshots of artifacts to. If not given, it defaults to the repository element.Information needed for deploying the web site of the project.

Relocation information of the artifact if it has been moved to a new group ID and/or artifact ID.

DescriptionWhether to assign snapshots a unique version comprised of the timestamp and build number, or to use the same version each time

Human readable name of the repository.The url of the repository, in the form protocol://hostname/path.The type of layout this repository uses for locating and storing artifacts - can be legacy or default.

DescriptionWhether to assign snapshots a unique version comprised of the timestamp and build number, or to use the same version each time

The name of the operating system to be used to activate the profile. This must be an exact match of the ${os.name} Java property, such as Windows XP.

The URL of the project's download page. If not given users will be referred to the homepage given by url. This is given to assist in locating artifacts that are not in the repository due to licensing restrictions.

Gives the status of this artifact in the remote repository. This must not be set in your local project, as it is updated by tools placing it in the reposiory. Valid values are: none (default), converted (repository manager converted this from an Maven 1 POM), partner (directly synced from a partner Maven 2 repository), deployed (was deployed from a Maven 2 instance), verified (has been hand verified as correct and final).

Default value is: true.A unique identifier for a repository. This is used to match the repository to configuration in the settings.xml file, for example. Furthermore, the identifier is used during POM inheritance and profile injection to detect repositories that should be merged.

Default value is: default.



DescriptionA unique identifier for a deployment location. This is used to match the site to configuration in the settings.xml file, for example.Human readable name of the deployment location.The url of the location where website is deployed, in the form protocol://hostname/path.

Describes where an artifact has moved to. If any of the values are omitted, it is assumed to be the same as it was before.

DescriptionThe group ID the artifact has moved to.The new artifact ID of the artifact.The new version of the artifact.An additional message to show the user about the move, such as the reason.

DescriptionHow to handle downloading of releases from this repository.How to handle downloading of snapshots from this repository.


DescriptionWhether to use this repository for downloading this type of artifact.

What to do when verification of an artifact checksum fails. Valid values are ignore , fail or warn (the default).


What to do when verification of an artifact checksum fails. Valid values are ignore , fail or warn (the default).

DescriptionIf true, then the default reports are not included in the site generation. This includes the reports in the "Project Info" menu.

A unique identifier for a repository. This is used to match the repository to configuration in the settings.xml file, for example. Furthermore, the identifier is used during POM inheritance and profile injection to detect repositories that should be merged.


A unique identifier for a repository. This is used to match the repository to configuration in the settings.xml file, for example. Furthermore, the identifier is used during POM inheritance and profile injection to detect repositories that should be merged.


Default value is: true.The frequency for downloading updates - can be always,daily (default), interval:XXX (in minutes) or never (only if it doesn't exist locally).

Default value is: true.The frequency for downloading updates - can be always,daily (default), interval:XXX (in minutes) or never (only if it doesn't exist locally).

Where to store all of the generated reports. The default is ${project.build.directory}/site .

Description

(Many) The reporting plugins to use and their configuration.

(Many) The dependencies specified here are not used until they are referenced in a POM within the group. This allows the specification of a "standard" version for a particular dependency.

Describes the licenses for this project. This is used to generate the license page of the project's web site, as well as being taken into consideration in other reporting and validation. The licenses listed for the project are that of the project itself, and not of dependencies.

This is the file specification used to activate the profile. The missing value will be the location of a file that needs to exist, and if it doesn't the profile will be activated. On the other hand exists will test for the existence of the file and if it is there the profile will be activated.

Settings Hierarchy

settingsRoot element of the user configuration file.

Element TypelocalRepository String

interactiveMode boolean

usePluginRegistry boolean

offline boolean

proxies/proxy* List<Proxy>

servers/server* List<Server>

mirrors/mirror* List<Mirror>profiles/profile* List<Profile>activeProfiles/activeProfile* List<String>pluginGroups/pluginGroup* List<String>

proxyThe <proxy> element contains informations required to a proxy settings.

Element Type

active boolean

protocol String

username Stringpassword String

port int

host StringnonProxyHosts String

id String

serverThe <server> element contains informations required to a server settings.

Element Typeusername Stringpassword StringprivateKey Stringpassphrase StringfilePermissions StringdirectoryPermissions Stringconfiguration DOM

id String

mirrorA download mirror for a given repository.

Element TypemirrorOf Stringname Stringurl String

id String

C:\Documents and Settings\894356\Desktop\SettingsComplete.txt

profileModifications to the build process which is keyed on some sort of environmental parameter.

Element Typeactivation Activation

Propertiesrepositories/repository* List<Repository>pluginRepositories/pluginRepository* List<Repository>

id String

activationThe conditions within the build runtime environment which will trigger the automatic inclusion of the parent build profile.

Element Type

activeByDefault boolean

jdk Stringos ActivationOSproperty ActivationPropertyfile ActivationFile

osThis is an activator which will detect an operating system's attributes in order to activate its profile.

Element Typename Stringfamily Stringarch Stringversion String

propertyThis is the property specification used to activate a profile. If the value field is empty, then the existence of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well.

Element Typename Stringvalue String

fileThis is the file specification used to activate a profile. The missing value will be a the location of a file that needs to exist, and if it doesn't the profile must run. On the other hand exists will test for the existence of the file and if it is there will run the profile.

Element Typemissing Stringexists String

repositoryRepository contains the information needed for establishing connections with remote repoistory

Element Typereleases RepositoryPolicysnapshots RepositoryPolicyid Stringname Stringurl String

layout String

releasesDownload policy

Element Type

enabled boolean

updatePolicy String

checksumPolicy String


snapshotsDownload policy

Element Type

enabled boolean

updatePolicy String

checksumPolicy String

pluginRepositoryRepository contains the information needed for establishing connections with remote repoistory

Element Typereleases RepositoryPolicysnapshots RepositoryPolicyid Stringname Stringurl String

layout String

DescriptionThe local repository.Whether Maven should attempt to interact with the user for input.

Whether Maven should use the plugin-registry.xml file to manage plugin versions.

Indicate whether maven should operate in offline mode full-time.

DescriptionWhether this proxy configuration is the active one.

The proxy protocol.

The proxy user.The proxy password.The proxy port.

The proxy host.The list of non-proxied hosts (delimited by |).No description.

DescriptionThe username used to authenticate.The password used in conjunction with the username to authenticate.The private key location used to authenticate.The passphrase used in conjunction with the privateKey to authenticate.The permissions for files when they are created.The permissions for directories when they are created.Extra configuration for the transport layer.No description.

DescriptionThe server ID of the repository being mirrored, eg "central". This MUST NOT match the mirror id.The optional name that describes the mirror.The URL of the mirror repository.No description.


Default value is: false.


(Many) Configuration for different proxy profiles. Multiple proxy profiles might come in handy for anyone working from a notebook or other mobile platform, to enable easy switching of entire proxy configurations by simply specifying the profile id, again either from the command line or from the defaults section below.

(Many) Configuration of server-specific settings, mainly authentication method. This allows configuration of authentication on a per-server basis.(Many) Configuration of download mirrors for repositories.(Many) Configuration of build profiles for adjusting the build according to environmental parameters.(Many) List of manually-activated build profiles, specified in the order in which they should be applied.(Many) List of groupIds to search for a plugin when that plugin groupId is not explicitly provided.


Default value is: http.

Default value is: 8080.




DescriptionThe conditional logic which will automatically trigger the inclusion of this profile.

No description.

The conditions within the build runtime environment which will trigger the automatic inclusion of the parent build profile.

DescriptionFlag specifying whether this profile is active as a default.

Specifies that this profile will be activated when a matching JDK is detected.Specifies that this profile will be activated when matching OS attributes are detected.Specifies that this profile will be activated when this System property is specified.Specifies that this profile will be activated based on existence of a file.

DescriptionThe name of the OS to be used to activate a profile.The general family of the OS to be used to activate a profile (e.g. 'windows')The architecture of the OS to be used to activate a profile.The version of the OS to be used to activate a profile.

This is the property specification used to activate a profile. If the value field is empty, then the existence of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well.

DescriptionThe name of the property to be used to activate a profile.The value of the property to be used to activate a profile.

This is the file specification used to activate a profile. The missing value will be a the location of a file that needs to exist, and if it doesn't the profile must run. On the other hand exists will test for the existence of the file and if it is there will run the profile.

DescriptionThe name of the file that should be missing to activate a profile.The name of the file that should exist to activate a profile.

DescriptionHow to handle downloading of releases from this repositoryHow to handle downloading of snapshots from this repositoryA unique identifier for a repository.Human readable name of the repository.The url of the repository.The type of layout this repository uses for locating and storing artifacts - can be "legacy" or "default".


What to do when verification of an artifact checksum fails - warn, fail, etc. Valid values are "fail" or "warn".

(Many) Extended configuration specific to this profile goes here. Contents take the form of property.value(Many) The lists of the remote repositories.(Many) The lists of the remote repositories for discovering plugins.




Default value is: true.The frequency for downloading updates - can be "always", "daily" (default), "interval:XXX" (in minutes) or "never" (only if it doesn't exist locally).


What to do when verification of an artifact checksum fails - warn, fail, etc. Valid values are "fail" or "warn".

DescriptionHow to handle downloading of releases from this repositoryHow to handle downloading of snapshots from this repositoryA unique identifier for a repository.Human readable name of the repository.The url of the repository.The type of layout this repository uses for locating and storing artifacts - can be "legacy" or "default".

Default value is: true.The frequency for downloading updates - can be "always", "daily" (default), "interval:XXX" (in minutes) or "never" (only if it doesn't exist locally).


This is the file specification used to activate a profile. The missing value will be a the location of a file that needs to exist, and if it doesn't the profile must run. On the other hand exists will test for the existence of the file and if it is there will run the profile.