The MAVEN Build Lifecycle

CLEAN LIFECYCLE pre-clean clean post-clean PHASE pre-clean clean post-clean executes processes needed prior to the actual project cleaning remove all files generated by the previous build executes processes needed to finalize the project cleaning plugin:goal clean:clean

Clean Lifecycle

DEFAULT LIFECYCLE validate initialize generate-sources process-sources generate-resources process-resources compile process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile process-test-classes test prepare-package package pre-integration-test integration-test post-integration-test verify install deploy validate the project is correct and all necessary information is available. initialize build state, e.g. set properties or create directories. generate any source code for inclusion in compilation. process the source code, for example to filter any values. generate resources for inclusion in the package. copy and process the resources into the destination directory, ready for packaging. compile the source code of the project. post-process the generated files from compilation, for example to do bytecode enhancement on Java classes. generate any test source code for inclusion in compilation. process the test source code, for example to filter any values. create resources for testing. copy and process the resources into the test destination directory. compile the test source code into the test destination directory run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed. take the compiled code and package it in its distributable format, such as a JAR. process and deploy the package if necessary into an environment where integration tests can be run. perform actions required after integration tests have been executed. This may including cleaning up the environment. run any checks to verify the package is valid and meets quality criteria. install the package into the local repository, for use as a dependency in other projects locally.

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

perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, proc

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

done in an integration or release environment, copies the final package to the remote repository for sharing with other deve Packaging Type: POM PHASE plugin:goal package site:attach-descriptor install install:install deploy deploy:deploy

Default Lifecycle

Packaging Type: JAR PHASE plugin:goal process-resources resources:resources compile compiler:compile process-test-resources resources:testResources test-compile compiler:testCompile test surefire:test package jar:jar

Default Lifecycle

install deploy

install:install deploy:deploy *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.

*JAR is the default packaging type

pre-site site post-site site-deploy PHASE pre-site site post-site site-deploy

SITE LIFECYCLE executes processes needed prior to the actual project site generation generates the project's site documentation executes processes needed to finalize the site generation, and to prepare for site deployment deploys the generated site documentation to the specified web server plugin:goal site:site site:deploy

Site Lifecycle

ytecode enhancement on Java classes.

do bytecode enhancement on Java classes. For Maven 2.0.5 and above.

t require the code be packaged or deployed.

ual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)

y involve things such as setting up the required environment.

e integration tests can be run.

is may including cleaning up the environment. other projects locally. to the remote repository for sharing with other developers and projects. Packaging Type: maven-plugin plugin:goal plugin:descriptor resources:resources compiler:compile resources:testResources compiler:testCompile surefire:test Packaging Type: EJB PHASE process-resources compile process-test-resources test-compile test package

PHASE generate-resources process-resources compile process-test-resources test-compile test

package jar:jar, plugin:addPluginArtifactMetadata install install:install, plugin:updateRegistry deploy deploy:deploy *Has goals that generate a descriptor file and perform some modifications to the repository data.

install 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.

re for site deployment

Packaging Type: EJB plugin:goal resources:resources compiler:compile resources:testResources compiler:testCompile surefire:test ejb:ejb

Packaging Type: WAR PHASE plugin:goal process-resources resources:resources compile compiler:compile process-test-resources resources:testResources test-compile compiler:testCompile test surefire:test package war:war

Packaging Type: EAR PHASE generate-resources process-resources package install deploy

install:install deploy:deploy

install deploy

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

ou must configurate the EJB plugin to package for EJB3, else the plugin defaults looks for the presence of certain EJB on files.

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

Packaging Type: EAR plugin:goal ear:generate-application-xml resources:resources ear:ear install:install deploy:deploy

Packaging Type: SWF PHASE plugin:goal compile flex2:compile-swc install install:install deploy deploy:deploy

R plugin has a goal named generate-applicationh generates the application.xml based upon the ation in the EAR project's POM.

Project Inheritance

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 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 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 SAMPLE 1 Directory structure . |-- my-module | `-- pom.xml `-- pom.xml com.mycompany.app:my-app:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <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 PO 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) SAMPLE 1 Directory structure

Project Aggregation

. |-- my-module | `-- pom.xml `-- pom.xml com.mycompany.app:my-app:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version> </project> To aggregate my-module into my-app <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-m

Project Inheritance vs Project Aggregation

If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and m 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

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 sam 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) SAMPLE 1 Directory structure . |-- my-module | `-- pom.xml `-- parent `-- pom.xml com.mycompany.app:my-app:1's POM

<project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version> </project> com.mycompany.app:my-app:1's POM <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> com.mycompany.app:my-module:1's 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>

Grouping Dependencies

If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. Y 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 wil project, don't forget to specify the dependency type as pom. SAMPLE 1 Consolidating Dependencies in a single POM Project

<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>

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 dependencie child relationships between projects and refactor all common dependencies to the parent project, but the disadvantage of the parent-child approach is that a 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 pom or using dependencyManagement in a parent POM.

OM. 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. to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.

SAMPLE 2 Directory structure . |-- my-module | `-- pom.xml `-- parent `-- pom.xml com.mycompany.app:my-app:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's 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>

ing 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 invo s modules as well.

Ms) SAMPLE 2 Directory structure

. |-- my-module | `-- pom.xml `-- parent `-- pom.xml com.mycompany.app:my-app:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1</version> </project> com.mycompany.app:my-module:1's POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-module</artifactId> <version>1</version> </project> To aggregate my-module into my-app <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>

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

ns, 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 pa

ou 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.

tion. 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 ha

Ms)

ou 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 depen ory. 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 t

Declaring a Dependency on a 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>

gth 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 ju s 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 depend

ndency POMs as it needs.

s 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 b

his setup, our module can now inherit some of the properties of our parent POM. y 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.

oing so, the parent project now knows its modules, and if a Maven command is invoked against the

1 as well. Furthermore, some commands (goals specifically) handle project aggregation differently.

parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and

modules. By doing so, you'd only have to build the parent and the rest will follow. have that parent project specify those Maven projects as its modules. You'd just have to apply all three

d create a special POM that does nothing more than declare a set of common dependencies. ed as transitive dependencies to your project. When you declare a dependency on this persistence-deps

need to share a large number of dependencies between projects, you could also just establish parentcan have only one parent. Sometimes it makes more sense to group similar dependencies together and

those dependencies one level down in the tree. Keep this in mind when choosing between grouping in a

Profile activation

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), complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in t 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 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

Profiles explicitly specified by using the -P CLI option

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

* When this option is specified, no profiles other than those specified in the option argument will be activated. Profiles with activation based on OS settings <profiles> <profile> <activation> <os> <name>Windows XP</name> <family>Windows</family> <arch>x86</arch> <version>5.1.2600</version> </os> </activation> ... </profile> </profiles>

Profiles activated when a file is missing

<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}.

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 confi

Profile deactivation
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 mvn groupId:artifactId:goal -P !profile-1,!profile-2 This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.

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

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

Profiles in external files 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 ch 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 <reposito 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

Profiles in POMs 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 m 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 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 dep 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 s

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 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 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 t 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 fi

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

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 m 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 hich 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.

) (deprecated in Maven 3.0: see Maven 3 compatibility notes))

Profiles activated through the Maven settings <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 activated when the system property "debug" is set with any value <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>) Profiles activated when the property "environment" is set with the "test" value

<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 profile in the pom is activated on the command line or through its activation config.

the command line by prefixing their identifier with either the character '!' or '-' as shown below:

es that would otherwise be activated through their activation config.

h type of profile

ccess to varying POM configuration options.

ot 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 repos the outcome of the build. Therefore, you will only be able to modify the <repositories> and <pluginRepositories> sections, plus an extra <properties> section. 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}.

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 therefo nformation to them without the risk of that information being unavailable to other users.

d the scenes)

s 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 for external profiles, the danger is limited. Another reason is that this POM info is sometimes being reused from the parent POM.

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 f 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 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 th n 2 is to consolidate all the information needed to run a build into a single file, or file hierarchy which is the POM.

triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in opment, testing, and production environments). Used properly, profiles can be used while still preserving which makes it more maintainable since it is runnning with one POM only.

Profiles triggered based on the detected state of the build environment <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 triggered based on the detected state of the build environment

<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 actived by default

<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.

below:

the result of the build is restricted to the inline profiles in the POM. Things like repository lists could nd <pluginRepositories> sections, plus an extra <properties> section. a plugin configuration in the form of ${profile.provided.path}.

hat project and it's sub-modules. Since these profiles are specified inline, and therefore have a better

o the repository system, making that person's build of that project completely unique es being reused from the parent POM.

ctive POM get deployed to a remote repository, any person can pickup its info out of the lements outside POM-profiles in settings.xml then most probably we cannot expect many files to configure is very confusing and very hard to maintain. Bottom line is that chy which is the POM.

CONFIGURING MAVEN PLUGINS (Introduction)

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 you will define a <pluginManagement/> element in a parent POM). For reporting plugins, you should specify each version in the <reporting><plugins/></r

GENERIC CONFIGURATION
Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element a Mojo maps to a goal).

Setting Global Plugin Parameters

Maven plugins (build and reporting) are configured by specifying a <configuration/> element where the child elements of the <configuration/> element 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 elemen Configuring a maven 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> Mapping Lists

<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 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 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 imple Unlike arrays, collections have no specific component type. In order to derive the type of a list item, the following strategy is used: 1. 2. 3. 4. If the XML element contains an implementation hint attribute, that is used If the XML tag contains a ., try that as a fully qualified class name Try the XML tag (with capitalized first letter) as a class in the same package as the mojo/object being configured If the element has no children, assume its type is String. Otherwise, the configuration will fail.

CONFIGURING BUILD PLUGINS

Using the <executions/> Tag
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 You can configure plugin parameters for specific executions of a plugin goal Setting Configuration Parameters in an Execution

<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 hi 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 you move a configuration section outside of the executions section, it will apply globally to all invocations of the plugin.

Using the <dependencies/> Tag

If you need to configure a plugin to use specific versions of dependencies, you can define these dependencies under a dependencies element under plugin. You could configure the dependencies of the Build plugins, commonly to use a more recent dependency version. Adding dependencies to a plugin

<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> * Example of a plugin configuration that overrides default dependency versions and adds new dependencies to facilitate goal execution.

Using the <inherited/> Tag In Build Plugins

By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited/> tag Using the <inherited/> Tag In Build Plugins <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 Default Command Line Execution Parameters

Configuring Plugin Parameters for Command Line Execution

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 ex

<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> * 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.

Setting Parameters for Goals Bound to Default Lifecycle

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 "def in the default lifecycle, and you can customize the configuration parameters of a separate goal execution. Setting a Parameter for a Default Goal Execution

<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> * 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.

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 se

CONFIGURING REPORTING PLUGINS

Using the <reportSets/> Tag
You 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 <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> * This example will generate only the project team report.

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.

Using the <inherited/> Tag In Reporting Plugins

Similar to the build plugins, to break the inheritance, you could uses the <inherited/> tag: Using the <inherited/> Tag In Reporting Plugins <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>

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

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 ignor

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 no <build/>.

be configured in the <build/> element. y should be configured in the <reporting/> element.

and version.

he 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 p porting plugins, you should specify each version in the <reporting><plugins/></reporting> elements (and surely in the <build><pluginManagement/></build> elements too

iguration/> 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 o

guration/> 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

r configuration, Maven will use the values defined directly under the plugin element for all goals which are executed in this plugin. Mapping Simple Objects

... <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> ...

Mapping Maps

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

nt being mapped. So in our case the person element must map to a person field in the mojo. elf. 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 and use that to search for the object to instantiate. ckage or have a more complicated name then you must specify this using an implementation attribute (<person implementation="com.mycompany.mojo.query.SuperPerson">

erive the type of a list item, the following strategy is used:

used

ackage as the mojo/object being configured he configuration will fail.

t commonly used for mojos that are intended to participate in some phases of the build lifecycle. al Setting Configuration Parameters in an Execution

<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> * 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.

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 s

re 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 inv apply globally to all invocations of the plugin.

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 se a more recent dependency version. Adding dependencies to a plugin

<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

o break the inheritance, you could uses the <inherited/> tag

or goals which are executed from the command-line. To do this, use the special execution id value of "default-cli".

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 t rs of a separate goal execution. Setting Two Default Goal Plugin Configuration Parameters

<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. if you need to configure two goals bound to the default lifecycle with separate settings for the same configuration parameter.

most commonly used to generate reports selectively when running mvn site.

e available report goals.

inherited/> tag:

n the pom have NOT the same behavior!

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 <bui

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 plug

ecify them in the <build><pluginManagement/></build> elements for each build plugins (generally, > elements (and surely in the <build><pluginManagement/></build> elements too).

ped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where

ped to fields, or setters, inside your Mojo (remember that a plug-in consists of one or more Mojos where

goals which are executed in this plugin. Mapping Complex Objects

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

Mapping Properties

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

o. ok in that package for an object named Person. As you can

on attribute (<person implementation="com.mycompany.mojo.query.SuperPerson">)

cycle. Setting Configuration Parameters in an Execution

<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> * 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.

of POMs. Executions of the same id from different POMs are merged. The same applies to

on. Instead they are only applied when the lifecycle phase they are bound to are invoked. Alternatively, if

he plugin executes, it will execute with a classpath that contains these dependencies.

id value of "default-cli".

goal>". You can customize the behavior of the Jar plugin's jar goal which is bound to the package phase

r the same configuration parameter.

arameters defined in the <configuration/> element of each plugin specified in <build/>.

, it will look up to a parameter defined in the <configuration/> element of each plugin specified in

Maven Properties

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 al ${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. Th

Maven Project Properties

When a Maven Project Property is referenced, the property name is referencing a property of the Maven Project Object Model (POM). Specifically, you are re 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 e 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 follo Property project.groupId project.version project.artifactId project.name project.description project.build.sourceDirectory project.build.scriptSourceDirectory project.build.testSourceDirectory project.build.outputDirectory project.build.testOutputDirectory project.build.directory basedir project.baseUri

maven.build.timestamp * 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.or

Maven Settings Properties

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 configura user.

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

Environment Variable Properties

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

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} in the Write-Once-Run-Anywhere (WORA) promise of the Java platform.

Java System Properties

Property java.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.name java.class.version java.class.path java.ext.dirs os.name os.arch os.version file.separator path.separator line.separator user.name user.home user.dir

Maven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() you can reference in a Maven property. The follow

User-defined 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 Pr 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>

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 w

mplicit properties are: an use the project.* prefix to reference values in a Maven POM. efix to reference values from your Maven Settings in ~/.m2/settings.xml. HOME can be referenced using the env.* prefix. he System.getProperty() method can be referenced as a Maven property.

ettings, 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 proj

ncing 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 e 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() m

en projects. Anything in a Maven POM can be referenced with a property. The following list shows some common property references from the Maven project. Description

The directory that the current project resides in. The directory that the current project resides in, represented as an URI. Since Maven 2.1.0 The timestamp that denotes the start of the build. Since Maven 2.1.0-M1

en.apache.org/ref/2.2.1/mavenmodel/maven.html ook at the JavaDoc for the maven-model project here http://maven.apache.org/ref/2.2.1/maven-model/apidocs/index.html

ch 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 config

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

resting environment variables are listed in the following list: Description Contains the current PATH in which Maven is running. The PATH contains a list of directories used to locate executable scripts and programs. (On *nix systems) this variable points to a user's home directory. Instead of referencing Contains the Java installation directory. This can point to either a Java Development Kit Contains the Maven 2 installation directory.

es 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

rieve from System.getProperty() you can reference in a Maven property. The following table lists available properties: Description Java Virtual Machine specification version Java Virtual Machine specification vendor Java vendor URL Java installation directory Java Virtual Machine specification version Java Virtual Machine specification vendor Java Virtual Machine specification name Java Virtual Machine implementation version Java Virtual Machine implementation vendor Java Virtual Machine implementation name Java Runtime Environment specification version Java Runtime Environment specification vendor Java Runtime Environment specification name Java class format version number Java class path Path of extension directory or directories Operating system name Operating system architecture Operating system version File separator ("/" on UNIX, "\" on Windows) Path separator (":" on UNIX, ";" on Windows) Line separator ("\n" on UNIX and Windows) User's account name User's home directory User's current working

n 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-define n 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>

rrounded by ${ and }. For example, to reference the project.version property, one would write:

ing sections provide some detail on the various properties available in a Maven project.

ng a property of the org.apache.maven.model.Model class which is being exposed as the implicit variable , when you reference ${project.version}, you are really invoking the getVersion() method on the instance 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>yyyyMMddHHmm</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.

2.2.1/maven-model/apidocs/index.html

h as the location of the local repository and any servers, profiles, and mirrors configured by a specific

${env.HOME}. If you do this, you'll end up with a more portable build that is more likely to adhere to

le lists available properties:

be referenced just like any other property available throughout Maven. User-defined properties can be

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

Resource Filtering

You can use Maven to perform variable replacement on project resources. When resource filtering is activated, Maven will scan resources for property refere 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 d Using Maven resource filtering you can reference Maven properties and then use Maven profiles to define different configuration values for different target d Resource filtering is disabled by default to prevent any unintentional resource filtering. To turn on resource filtering, you need to use the resources chi SAMPLE 1 src/main/resources/applicationContext.xml

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://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 2 src/main/command/run.bat

@echo off java -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, M referenced in a POM using ${...} notation, you can reference variables in your project's resources using the same syntax. SAMPLE 3 src/main/resources/service.xml

<service> <!-- This URL was set by project version ${project.version} --> <url>${jdbc.url}</url> <user>${jdbc.username}</user> <password>${jdbc.password}</password> </service>

src/main/filters/default.properties jdbc.url=jdbc:hsqldb:mem:mydb jdbc.username=sa jdbc.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 resources into separate directories under src/main. Assume that you have a project which contains hundreds of XML documents and hundreds of images. In 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 conf Configuring Additional Resource Directories

<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>

ources. 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 m a POM. This feature is especially helpful when you need to parameterize a build with different configuration values depending on the target deployment platform. and then use Maven profiles to define different configuration values for different target deployment environments. ntional resource filtering. To turn on resource filtering, you need to use the resources child element of the build element in a POM. pom.xml <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

m 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 w les in your project's resources using the same syntax.

pom.xml <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.

ed 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 i u 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 of resource directories, you would add the following resource elements to your build configuration.

ed by ${ and }. When it finds these references it will replace them with the appropriate value in much the same way uration values depending on the target deployment platform. ironments. he build element in a POM. Results $ 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 off java -jar simple-cmd-2.3.1.jar %*

o apply a filter to the resources that allows you to replace tokens within resource file. Just like variables are

Results $ mvn install ... $ cat target/classes/service.xml ... <service> <!-- This URL was set by project version ${project.version} --> <url>jdbc:hsqldb:mem:mydb</url> <user>sa</user> <password></password> </service> ...

ould also note that you don't need to consolidate all of your resources into a single directory. You can always separate g the resources in the src/main/resources directory, you might want to create two directories src/main/xml and

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 check whether a profile is active for a given build

To excecute a maven plugin To excecute a file

$ 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 groupId:artifactId:version:goal $mvn -e install -f auditpom.xml

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

If project list is specified, also build projects required by the list If project list is specified, also build projects that depend on projects on the list Run in non-interactive (batch) mode Warn if checksums don't match Fail the build if checksums don't match Force upToDate check for any relevant registered plugins Define a system property Produce execution error messages Encrypt master security password Encrypt server password Force the use of an alternate POM file Only fail the build afterwards; allow all non-impacted builds to continue Stop at first failure in reactorized builds NEVER fail the build, regardless of project result Alternate path for the global settings file Display help information Do not recurse into sub-projects Don't use ~/.m2/plugin-registry.xml for plugin versions Suppress upToDate check for any relevant registered plugins Work offline Comma-delimited list of profiles to activate Build specified reactor projects instead of all projects Quiet output - only show errors Dynamically build reactor from subdirectories Resume reactor from specified project Alternate path for the user settings file Forces a check for updated releases and snapshots on remote repositories Synonym for cpu Display version information Display version information WITHOUT stopping build Produce execution debug output

MAVEN TIPS
To prevent: "[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!" <project> ... <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> ... </project> To set up Maven so it will compile with a target and source JVM of my choice ... <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> ... To include tools.jar in my dependencies ... <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> Disabling Maven Meta Information

<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> To add plugin's goals to phases in your 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> ... Minimal POM <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.app</groupId> <artifactId>my-app</artifactId> <version>1.0.0</version> </project> What is a Mojo? 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. Maven is configured to look for plugins in two groups: org.apache.maven.plugins (core Maven plugins) org.codehaus.mojo (extra plugins) Maven Standard Directory Layout src src/main/java src/main/resources src/main/filters src/main/assembly src/main/config src/main/webapp src/test/java src/test/resources

src/test/filters src/site target LICENSE.txt NOTICE.txt README.txt You can always separate resources into separate directories under src/main <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> To change the default behavior of the SureFire plugin (Produce output instead of stopping a build whenever a unit test failure is encount <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <testFailureIgnore>true</testFailureIgnore> </configuration> </plugin> ... </plugins> </build> To install an artifact into the local repository mvn install:install-file -Dfile=commons-lang-2.1.0.jar -DgroupId=swh-libs.p2g.commonsjars -DartifactId=commons-lang -Dversion=2.1.0 -Dpackaging=jar -DgeneratePom=true

ally) to copy filtered resources, i.e. build is platform dependent!"

of my choice

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.

Directory contains all of the source material for building the project, its site and so on Application/Library sources Application/Library resources Resource filter files Assembly descriptors Configuration files Web application sources Test sources Test resources

er src/main

Test resource filter files Site directory is used to house all output of the build Project's license Notices and attributions required by libraries that the project depends on Project's readme

utput instead of stopping a build whenever a unit test failure is encountered)

Project Hierarchy
project The <project> element is the root of the descriptor. The following table lists all of the possible child elements. Element modelVersion parent groupId artifactId version packaging name description url inceptionYear organization licenses/license* mailingLists/mailingList* developers/developer* contributors/contributor* issueManagement scm ciManagement prerequisites build profiles/profile* distributionManagement modules/module* repositories/repository* pluginRepositories/pluginRepository* dependencies/dependency* reports reporting dependencyManagement properties/key =value * parent The <parent> element contains informations required to the parent project. Element Type String Parent String String String String String String String String Organization List<License> List<MailingList> List<Developer> List<Contributor> IssueManagement Scm CiManagement Prerequisites Build List<Profile> DistributionManagement List<String> List<Repository> List<Repository> List<Dependency> DOM Reporting DependencyManagement Properties Type

artifactId groupId version

String String String

relativePath

String

organization Specifies the organization that produces this project. Element name url String String Type

license 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 r Element name url distribution String String String Type

comments

String

mailingList This element describes all of the mailing lists associated with a project. The auto-generated site references this information. Element name subscribe unsubscribe post archive otherArchives/otherArchive* developer Information about one of the committers on this project. Element id name email url organization organizationUrl roles/role* timezone properties/key =value * String String String String String String List<String> String Properties Type String String String String String List<String> Type

contributor 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 patch Element name String Type

email url organization organizationUrl roles/role* timezone properties/key =value *

String String String String List<String> String Properties

issueManagement Information about the issue tracking (or bug tracking) system used to manage this project. Element system url scm The <scm> element contains informations required to the SCM (Source Control Management) of the project. Element connection developerConnection tag url String String String String Type String String Type

ciManagement The <CiManagement> element contains informations required to the continuous integration system of the project. Element system url notifiers/notifier* notifier Configures one method for notifying users/developers when a build breaks. Element type sendOnError sendOnFailure sendOnSuccess sendOnWarning address configuration/key =value * prerequisites Describes the prerequisites a project can have. Element maven build The <build> element contains informations required to build the project. String Type String boolean boolean boolean boolean String Properties Type Type String String List<Notifier>

Element sourceDirectory scriptSourceDirectory testSourceDirectory outputDirectory testOutputDirectory extensions/extension* defaultGoal resources/resource* testResources/testResource* directory finalName filters/filter* pluginManagement plugins/plugin* extension Describes a build extension to utilise. Element groupId artifactId version String String String String String String

Type

String String List<Extension> String List<Resource> List<Resource> String String List<String> PluginManagement List<Plugin>

Type

resource This element describes all of the classpath resources associated with a project or unit tests. Element targetPath String Type

filtering

boolean

mergeId directory includes/include* excludes/exclude*

String String List<String> List<String>

testResource This element describes all of the classpath resources associated with a project or unit tests. Element targetPath String Type

filtering

boolean

mergeId directory includes/include* excludes/exclude* pluginManagement Section for management of default plugin information for use in a group of POMs. Element plugins/plugin* plugin The <plugin> element contains informations required for a plugin. Element groupId artifactId version extensions executions/execution* dependencies/dependency* goals inherited configuration execution The <execution> element contains informations required for the execution of a plugin. Element id phase goals/goal* inherited configuration dependency The <dependency> element contains information about a dependency of the project. Element groupId artifactId version

String String List<String> List<String>

Type List<Plugin>

Type String String String boolean List<PluginExecution> List<Dependency> DOM String DOM

Type String String List<String> String DOM

Type String String String

type

String

classifier scope

String String

systemPath

String

exclusions/exclusion* optional

List<Exclusion> boolean

exclusion The <exclusion> element contains informations required to exclude an artifact to the project. Element artifactId groupId String String Type

profile Modifications to the build process which is activated based on environmental parameters or command line arguments. Element id activation build distributionManagement modules/module* repositories/repository* pluginRepositories/pluginRepository* dependencies/dependency* reports reporting dependencyManagement properties/key =value * String Activation BuildBase DistributionManagement List<String> List<Repository> List<Repository> List<Dependency> DOM Reporting DependencyManagement Properties Type

activation The conditions within the build runtime environment which will trigger the automatic inclusion of the build profile. Element activeByDefault jdk os property file boolean String ActivationOS ActivationProperty ActivationFile Type

os This is an activator which will detect an operating system's attributes in order to activate its profile. Element name family arch version String String String String Type

property 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, othe

Element name value String String

Type

file 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 Element missing exists String String Type

distributionManagement 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. Element repository snapshotRepository site downloadUrl relocation status Type DeploymentRepository DeploymentRepository Site String Relocation String

repository Repository contains the information needed for deploying to the remote repository. Element uniqueVersion id name url layout snapshotRepository Repository contains the information needed for deploying to the remote repository. Element uniqueVersion id name url layout site Contains the information needed for deploying websites. Element id name url String String String Type boolean String String String String Type boolean String String String String Type

relocation 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.

Element groupId artifactId version message String String String String

Type

pluginRepository A repository contains the information needed for establishing connections with remote repository. Element releases snapshots id name url layout releases Download policy. Element enabled updatePolicy checksumPolicy snapshots Download policy. Element enabled updatePolicy checksumPolicy reporting Section for management of reports and their configuration. Element excludeDefaults outputDirectory plugins/plugin* dependencyManagement Section for management of default dependency information for use in a group of POMs. Element dependencies/dependency* Type List<Dependency> Type Boolean String List<ReportPlugin> boolean String String Type boolean String String Type Type RepositoryPolicy RepositoryPolicy String String String String

Description Declares to which version of project descriptor this POM conforms. 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 current version of the artifact produced by this project. 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. The full name of the project. 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 URL to the project's homepage. 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. 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. (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>.

Description

The 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. 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.

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

e, 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. Description The full legal name of the license. The official url for the license text. The primary method by which this project may be distributed. repo may be downloaded from the Maven repository manual user must manually download and install the dependency. Addendum information pertaining to this license.

nces this information. Description The name of the mailing list. 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. The link to a URL where you can browse the mailing list archive. (Many) The link to alternate URLs where you can browse the list archive.

Description The 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. (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. The timezone the contributor is in. This is a number in the range -11 to 12. (Many) Properties about the contributor, such as an instant messenger handle.

Usually, these contributions come in the form of patches submitted. Description 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. (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. The timezone the contributor is in. This is a number in the range -11 to 12. (Many) Properties about the contributor, such as an instant messenger handle.

Description The name of the issue management system, e.g. Bugzilla URL for the issue management system used by the project.

Description 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. 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. Default value is: HEAD. The URL to the project's browsable SCM repository, such as ViewVC or Fisheye.

Description The 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. (Many) Configuration for notifying developers/users when a build is unsuccessful, including user information and notification mode.

Description The mechanism used to deliver notifications. Default value is: mail. Whether to send notifications on error. Default value is: true. Whether to send notifications on failure. Default value is: true. Whether to send notifications on success. Default value is: true. Whether to send notifications on warning. Default value is: true. Deprecated. Where to send the notification to - eg email address. (Many) Extended configuration specific to this notifier goes here.

Description The minimum version of Maven required to build the project, or to use this plugin. Default value is: 2.0.

Description 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. The directory where compiled application classes are placed. The directory where compiled test classes are placed. (Many) A set of build extensions to use from this project. The default goal (or phase in Maven 2) to execute when none is specified for the 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 directory where all files generated by the build are placed. 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.

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

Description 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. Describe the directory where the resources are stored. The path is relative to the POM. (Many) A list of patterns to include, e.g. **/*.xml. (Many) A list of patterns to exclude, e.g. **/*.xml

Description 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. Describe the directory where the resources are stored. The path is relative to the POM. (Many) A list of patterns to include, e.g. **/*.xml. (Many) A list of patterns to exclude, e.g. **/*.xml

Description (Many) The list of plugins to use.

Description The group ID of the plugin in the repository. Default value is: org.apache.maven.plugins. The artifact ID of the plugin in the repository. The version (or valid range of versions) of the plugin to be used. 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. Whether any configuration should be propagated to child POMs. The configuration as DOM object.

Description 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. Whether any configuration should be propagated to child POMs. The configuration as DOM object.

Description The 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. 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.

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

Description The 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. 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>.

Description 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 matching operating system 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.

Description 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 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.

e of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well.

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

hat 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. Description The name of the file that must be missing to activate the profile. The name of the file that must exist to activate the profile.

t of artifacts and the site produced by the build. Description Information 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. 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. Relocation information of the artifact if it has been moved to a new group ID and/or artifact ID. 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).

Description Whether to assign snapshots a unique version comprised of the timestamp and build number, or to use the same version each time 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. 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. Default value is: default.

Description Whether to assign snapshots a unique version comprised of the timestamp and build number, or to use the same version each time 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. 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. Default value is: default.

Description A 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.

me as it was before.

Description The 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.

Description How to handle downloading of releases from this repository. How to handle downloading of snapshots from this repository. 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. 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. Default value is: default.

Description Whether to use this repository for downloading this type of artifact. 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. Valid values are ignore , fail or warn (the default).

Description Whether to use this repository for downloading this type of artifact. 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. Valid values are ignore , fail or warn (the default).

Description If true, then the default reports are not included in the site generation. This includes the reports in the "Project Info" menu. Where to store all of the generated reports. The default is ${project.build.directory}/site . (Many) The reporting plugins to use and their configuration.

Description (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.

d not of dependencies.

he profile will be activated.

Settings Hierarchy
settings Root element of the user configuration file. Element localRepository interactiveMode usePluginRegistry offline proxies/proxy* servers/server* mirrors/mirror* profiles/profile* activeProfiles/activeProfile* pluginGroups/pluginGroup* proxy The <proxy> element contains informations required to a proxy settings. Element active protocol username password port host nonProxyHosts id server The <server> element contains informations required to a server settings. Element username password privateKey passphrase filePermissions directoryPermissions configuration id mirror A download mirror for a given repository. Element mirrorOf name url String String String Type String String String String String String DOM String Type boolean String String String int String String String Type String boolean boolean boolean List<Proxy> List<Server> List<Mirror> List<Profile> List<String> List<String> Type

id

String

profile Modifications to the build process which is keyed on some sort of environmental parameter. Element activation properties/key =value * repositories/repository* pluginRepositories/pluginRepository* id Type Activation Properties List<Repository> List<Repository> String

activation The conditions within the build runtime environment which will trigger the automatic inclusion of the parent build profile. Element activeByDefault jdk os property file boolean String ActivationOS ActivationProperty ActivationFile Type

os This is an activator which will detect an operating system's attributes in order to activate its profile. Element name family arch version String String String String Type

property 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, othe Element name value String String Type

file 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 ru Element missing exists String String Type

repository Repository contains the information needed for establishing connections with remote repoistory Element releases snapshots id name url layout releases Download policy Element Type Type RepositoryPolicy RepositoryPolicy String String String String

enabled updatePolicy checksumPolicy snapshots Download policy Element enabled updatePolicy checksumPolicy

boolean String String

Type boolean String String

pluginRepository Repository contains the information needed for establishing connections with remote repoistory Element releases snapshots id name url layout Type RepositoryPolicy RepositoryPolicy String String String String

Description The local repository. Whether Maven should attempt to interact with the user for input. Default value is: true. Whether Maven should use the plugin-registry.xml file to manage plugin versions. Default value is: false. Indicate whether maven should operate in offline mode full-time. 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.

Description Whether this proxy configuration is the active one. Default value is: true. The proxy protocol. Default value is: http. The proxy user. The proxy password. The proxy port. Default value is: 8080. The proxy host. The list of non-proxied hosts (delimited by |). No description. Default value is: default.

Description The 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. Default value is: default.

Description The 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: default.

Description The conditional logic which will automatically trigger the inclusion of this profile. (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. No description. Default value is: default.

arent build profile. Description Flag specifying whether this profile is active as a default. Default value is: false. 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.

The The The The

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

e of the named property will activate the profile, otherwise it does a case-sensitive match against the property value as well. Description The name of the property to be used to activate a profile. The value of the property to be used to activate a profile.

hat 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. Description The name of the file that should be missing to activate a profile. The name of the file that should exist to activate a profile.

Description How to handle downloading of releases from this repository How to handle downloading of snapshots from this repository A 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: default.

Description

Whether to use this repository for downloading this type of artifact. 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".

Description Whether to use this repository for downloading this type of artifact. 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".

Description How to handle downloading of releases from this repository How to handle downloading of snapshots from this repository A 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: default.