Project Object Model – What is POM?


What is POM
A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this are the build directory, which is target; the source directory, which is src/main/java; the test source directory, which is src/main/test; and so on.
The POM was renamed from project.xml in Maven 1 to pom.xml in Maven 2. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.
Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.

Super POM
The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects. The snippet below is the Super POM for Maven 2.0.x.
The snippet below is the Super POM for Maven 2.0.x.
Maven Default Project

Maven Repository Switchboard


Maven Plugin Repository


















Minimal POM
The minimum requirement for a POM are the following:

  • project root
  • modelVersion – should be set to 4.0.0
  • groupId – the id of the project’s group.
  • artifactId – the id of the artifact (project)
  • version – the version of the artifact under the specified group

Here’s an example:


A POM requires that its groupId, artifactId, and version be configured. These three values form the project’s fully qualified artifact name. This is in the form of ::. As for the example above, its fully qualified artifact name is “”.
Every Maven project has a packaging type. If it is not specified in the POM, then the default value “jar” would be used.
Project inheritance
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

The Super POM is one example of project inheritance, however you can also introduce your own parent POMs by specifying the parent element in the POM, as demonstrated in the following examples.

Tagged : / / / / / / / / / / / /

Reporting Plugins in Maven | Maven Plugins That Provide Reports


Reporting plugins
Plugins which generate reports, are configured as reports in the POM and run under the site generation

This plugin consists of several reports that you can run selectively, individually or even run all of them. Please see below for instructions on how to configure your pom.xml to do this.

Run All Reports
To include all Project Info Reports in your project, you must configure your pom.xml. Use “mvn site:site” to generate the configured reports.



Run Selective Reports



Reporting plugins are configured in the POM as in this example:


Configuration in the reporting section also applies if plugin goals are invoked individually. The converse is not true– if you configure the plugin inside , that configuration will NOT apply to .

Configuring multiple reports for one plugin using . Each must have a unique . For more information on UMLGraph, see the UMLGraph site and this page.










Plugins Type Version Release Date Description Source Repository Issue Tracking
changelog R 2.1 2007-07-25 Generate a
list of recent
changes from
your SCM.
changes B+R 2.1 2008-11-24 Generate a
report from
issue tracking
or a change
checkstyle B+R 2.3 2009-07-14 Generate a
clover B+R 2.4 2007-04-23 Generate
a Clover
report. NOTE:
Moved to
doap B 1.0 2008-08-01 Generate a
of a Project
(DOAP) file
from a POM.
docck B 1.0 2008-11-16 Documentation
javadoc B+R 2.6 2009-07-29 Generate
Javadoc for
the project.
Jxr R 2.1 2007-04-05 Generate a
source cross
pmd B+R 2.4 2008-01-08 Generate a
PMD report.
projectinforeports R 2.1.2 2009-07-23 Generate
surefirereport R 2.4.3 2008-05-14 Generate a
report based
on the results
of unit tests.

Known Plugins That Provide Reports


Tagged : / / / / / / / / / / / /

Properties in Maven – List of Maven Properties


It is a collection of things found in the offcial maven documentation and postings to the maven user mailing list.
Build in properties

  • ${basedir} represents the directory containing pom.xml
  • ${version} equivalent to ${project.version} or ${pom.version}

Pom/Project properties
All elements in the pom.xml, can be referenced with the project. prefix or using pom. as prefix. This list is just an example of some commonly used elements.

  • ${} results in the path to your “target” dir, this is the same as ${}
  • ${} results in the path to your “target/classes” dir
  • ${} or ${} refers to the name of the project.
  • ${project.version} or ${pom.version} refers to the version of the project.
  • ${} refers to the final name of the file created when the built project is packaged

Local user settings
Similarly, values in the user’s settings.xml can be referenced using property names with settings. prefix.

  • ${settings.localRepository} refers to the path of the user’s local repository.
  • ${maven.repo.local} also works for backward compatibility with maven1 ??

Environment variables
Environment variables can be referenced using the env prefix

  • ${env.M2_HOME} returns the Maven2 installation path.
  • ${java.home} specifies the path to the current JRE_HOME environment use with relative paths to get for example:

Java system properties
All Java System Properties defined by the JVM.
Custom properties in the POM
User defined properties in the pom.xml.


  • ${my.filter.value} will result in hello if you inserted the above XML fragment in your pom.xml

Parent Project variables
How can parent project variables be accessed?
You can use the prefix: ${project.parent}.
A good way to determine possible variables is to have a look directly at the API. I’m currently using Maven 2.2.1, and to access the Parent you can use ${project.parent}. This will return an org.apache.maven.project.MavenProject instance.
To access the parent version: ${parent.version}.
Reflection Properties
The pattern ${someX.someY.someZ} can simply sometimes mean getSomeX().getSomeY().getSomeZ(). Thus, properties such as ${} is translated to getProject().getBuild().getDirectory().
List of Maven Properties

project (from [1])
o project.distributionManagementArtifactRepository
o project.artifact
o project.parent
o project.file
o project.artifacts
o project.parentArtifact
o project.pluginArtifacts
o project.remoteArtifactRepositories
o project.pluginArtifactRepositories
o project.attachedArtifact
* settings (from [2])
o settings.offilne
o settings.interactive
* rootless (from [3])
o localRepository
o reactorProjects
* java properties (from [4])
o java.version
o java.vendor
o java.vendor.url
o java.home
o java.vm.specification.version
o java.vm.specification.vendor
o java.vm.version
o java.vm.vendor
o java.specification.version
o java.specification.vendor
o java.class.version
o java.class.path
o java.library.path
o java.compiler
o java.ext.dirs
o os.arch
o os.version
o file.separator
o path.separator
o line.separator
o user.home
o user.dir


Tagged : / / / / / / / / / / / / /

Profiles in Maven – How to Build Maven Profile ?


Reference: Apache Maven,Current version User Guide

Profiles in Maven

 Use of profile:

Maven 2.0 goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inhertiance,
dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.

However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different
dependency set will be required, and the project’s artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.

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

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

• Per Project: Defined in the POM itself (pom.xml).
• Per User: Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
• Global: Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
• Profile descriptor: a descriptor located in project basedir (profiles.xml)

How can a profile be triggered? How does this vary according to the type of profile being used?

  • A profile can be triggered/activated in several ways:
  • Explicitly
  • Through Maven settings
  • Based on environment variables
  • OS settings
  • Present or missing files

Profiles can be explicitly specified using the -P CLI option.

This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.

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

Profiles can be activated in the Maven settings, via the section.

This section takes a list of elements, each containing a profile-id inside.


Profiles listed in the tag would be activated by default everytime a project use it.

Profiles can be automatically triggered based on the detected state of the build environment.

These triggers are specified via an section in the profile itself. Currently, this detection is
limited to prefix-matching of the JDK version, the presence of a system property or the value of a
system property. Here are some examples.
The follwing 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”):


The following honours versions 1.3, 1.4 and 1.5.


Note: an upper bound such as ,1.5] is likely not to include most releases of 1.5, since they will have an additional “patch” release such as _05 that is not taken into consideration in the above range.

This next one will activate based on OS settings.

See the Maven Enforcer Plugin for more details about OS values.

Windows XP

This will activate the profile when the system property “debug” is specified with any value:


This example will trigger the profile when the system property “environment” is specified with the
value “test”:


Note: Environment variable FOO would be set like env.FOO.

Present or missing files

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

This example will trigger the profile when the generated file target/generated-sources/axistools/wsdl2java/org/apache/maven is missing.


Note: The tags and could be interpolated with some patterns like ${user.home}. Profiles can also be active by default using a configuration like the following:



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. All profiles that are active by default are automatically deactivated when a profile in the pom is activated on the command line or through its activation config.

Deactivating a profile

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

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

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

Next ….? Coming Soon

Tagged : / / / / / / / / / / / /

issue Management in Maven



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

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


Tagged : / / / / / / / / /

Introduction of Maven – Complete Guide


What is Maven?
Philosophy of Maven
Benefits of Maven
High Level Features and Benefits of Maven
Download Maven
Installation Instructions
Windows 2000/XP
Unix-based Operating Systems (Linux, Solaris and Mac OS X)
Optional configuration
Settings Reference
First Maven project?

What is Maven?

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.
At first glance Maven can appear to be many things, but in a nutshell Maven is an attempt to apply patterns to a project’s build infrastructure in order to promote comprehension and productivity by providing a clear path in the use of best practices. Maven is essentially a project management and comprehension tool and as such provides a way to help with managing:

  • Builds
  • Documentation
  • Reporting
  • Dependencies
  • SCMs
  • Releases
  • Distribution

Philosophy of Maven

Maven is generally considered by many to be a build tool. Many people who come to Maven initially are familiar with Ant so it’s a natural association but Maven is not just a build tool, and not just a replacement for Ant. Maven is an entirely different creature from Ant. Ant is simply a toolbox whereas Maven is about the application of patterns in order to achieve an infrastructure which displays the characteristics of visibility, reusability, maintainability, and comprehensibility.
Maven was borne of the very practical desire to make several projects at Apache work in the same way. So that developers could freely move between these projects, knowing clearly how they all worked by understanding how one of them worked. If a developer spent time understanding how one project built it was intended that they would not have to go through this process again when they moved on to the next project. The same idea extends to testing, generating documentation, generating metrics and reports, testing and deploying.

Benefits of Maven

  • Standardized project layout and project structure generator.
  • Standardized dependency-management mechanism.
  • Multiple project support.
  • Instant downloads of new plugins and features as the developer needs them.
  • Website generation for up-to-date project information.
  • Integration with source control: CVS and Subversion.
  • Reusability
  • scalability (lower level of additional info/code to add a new step to the build process)
  • Build lifecycle management
  • Large existing repository
  • Eclipse aware
  • Well documented (hopefully soon)
  • One directory layout,
  • A single way to define dependencies,
  • Setting up a project is really fast,
  • 99% of my needs are available out of the box,
  • build best practices enforcement (shared build meme)
  • automated build of application, from source code to pre-production platform => fast time to market with reduced risks
  • Works well with distributed teams 😉 Location doesn’t matter.
  • All artifacts are versioned and store in a repository
  • Build process is standardized for all projects
  • A lot of goals are available so it isn’t necessary to develop some specific build process part contrary to ANT we can reuse existing ANT tasks in build process with ant run plug-in
  • it provide quality project information with generated site
  • Easy to learn and use
  • Makes the build process much easier at the project level (i.e. don’t have to create very much for each project for Maven to build it correctly, and those things you do create are more declarative than functional)
  • Automatic project web sites with consistent information about each project
  • Recommended standards and best practices for project layout and definition
  • Promotes modular design of code. by making it simple to manage mulitple projects it allows the design to be laid out into multiple logical parts, weaving these parts together through the use of dependency tracking in pom files.
  • Enforces modular design of code
  • Quick project setup, no complicated build.xml files, just a POM and go


High Level Features and Benefits of Maven

  • Encourages best practices
  • Provides a uniform build system and consistent usage across all projects
  • Provides dependency management including automatic updating, dependency closures (also known as transitive dependencies)
  • Provides reuse of build logic
  • Defines project standard directory layout
  • Helps to reduce the duplication of dependent software libraries (jars) required to build an application
  • Stores all the software libraries or artifacts in a remote stores called a Maven repositories

Download Maven

Maven is distributed in several formats for your convenience. Maven 2.2.1 is distributed under the Apache License, version 2.0.
Download link:

Installation Instructions

System Requirements
JDK 1.5 or above (this is to execute Maven – it still allows you to build against 1.3 and prior JDK’s)
Memory No minimum requirement
Disk No minimum requirement. Approximately 100MB will be used for your local repository, however this will vary depending on usage and can be removed and redownloaded at any time.
Operating System No minimum requirement. On Windows, Windows NT and above or Cygwin is required for the startup scripts. Tested on Windows XP, Fedora Core and Mac OS X.
Maven is a Java tool, so you must have Java installed in order to proceed. More precisely, you need a Java Development Kit (JDK), the Java Runtime Environment (JRE) is not sufficient.
Additional optional installation steps are listed after the platform specific instructions.

Windows 2000/XP

  • Unzip the distribution archive, i.e. to the directory you wish to install Maven 2.2.1. These instructions assume you chose C:\Program Files\Apache Software Foundation. The subdirectory apache-maven-2.2.1 will be created from the archive.
  • Add the M2_HOME environment variable by opening up the system properties (WinKey + Pause), selecting the “Advanced” tab, and the “Environment Variables” button, then adding the M2_HOME variable in the user variables with the value C:\Program Files\Apache Software Foundation\apache-maven-2.2.1. Be sure to omit any quotation marks around the path even if it contains spaces. Note: For Maven < 2.0.9, also be sure that the M2_HOME doesn’t have a ‘\’ as last character.
  • In the same dialog, add the M2 environment variable in the user variables with the value %M2_HOME%\bin.
  • Optional: In the same dialog, add the MAVEN_OPTS environment variable in the user variables to specify JVM properties, e.g. the value -Xms256m -Xmx512m. This environment variable can be used to supply extra options to Maven.
  • In the same dialog, update/create the Path environment variable in the user variables and prepend the value %M2% to add Maven available in the command line.
  • In the same dialog, make sure that JAVA_HOME exists in your user variables or in the system variables and it is set to the location of your JDK, e.g. C:\Program Files\Java\jdk1.5.0_02 and that %JAVA_HOME%\bin is in your Path environment variable.
  • Open a new command prompt (Winkey + R then type cmd) and run mvn –version to verify that it is correctly installed.

Unix-based Operating Systems (Linux, Solaris and Mac OS X)

  • Extract the distribution archive, i.e. apache-maven-2.2.1-bin.tar.gz to the directory you wish to install Maven 2.2.1. These instructions assume you chose /usr/local/apache-maven. The subdirectory apache-maven-2.2.1 will be created from the archive.
  • In a command terminal, add the M2_HOME environment variable, e.g. export M2_HOME=/usr/local/apache-maven/apache-maven-2.2.1.
  • Add the M2 environment variable, e.g. export M2=$M2_HOME/bin.
  • Optional: Add the MAVEN_OPTS environment variable to specify JVM properties, e.g. export MAVEN_OPTS=”-Xms256m -Xmx512m”. This environment variable can be used to supply extra options to Maven.
  • Add M2 environment variable to your path, e.g. export PATH=$M2:$PATH.
  • Make sure that JAVA_HOME is set to the location of your JDK, e.g. export JAVA_HOME=/usr/java/jdk1.5.0_02 and that $JAVA_HOME/bin is in your PATH environment variable.
  • Run mvn –version to verify that it is correctly installed.


Optional configuration

Maven will work for most tasks with the above configuration, however if you have any environmental specific configuration outside of individual projects then you will need to configure settings. The following sections refer to what is available.


Maven has settings file located in the Maven installation and/or user home directory that configure environmental specifics such as:

  • HTTP proxy server
  • repository manager location
  • server authentication and passwords
  • other configuration properties

Settings Reference

The settings element in the settings.xml file contains elements used to define values which configure Maven execution in various ways, like the pom.xml, but should not be bundled to any specific project, or distributed to an audience. These include values such as the local repository location, alternate remote repository servers, and authentication information. There are two locations where a settings.xml file may live:

    • The Maven install: $M2_HOME/conf/settings.xml
    • A user’s install: ${user.home}/.m2/settings.xml

Here is an overview of the top elements under settings:



localRepository: This value is the path of this build system’s local repository. The default value is ${user.home}/.m2/repository. This element is especially useful for a main build server allowing all logged-in users to build from a common local repository.

interactiveMode: true if Maven should attempt to interact with the user for input, false if not. Defaults to true.

usePluginRegistry: true if Maven should use the ${user.home}/.m2/plugin-registry.xml file to manage plugin versions, defaults to false. Note that for the current version of Maven 2.0, the plugin-registry.xml file should not be depended upon. Consider it dormant for now.

offline: true if this build system should operate in offline mode, defaults to false. This element is useful for build servers which cannot connect to a remote repository, either because of network setup or security reasons.

pluginGroups: This element contains a list of pluginGroup elements, each contains a groupId. The list is searched when a plugin is used and the groupId is not provided in the command line. This list automatically contains org.apache.maven.plugins and org.codehaus.mojo. For example, given the above settings the Maven command line may execute org.mortbay.jetty:jetty-maven-plugin:run with the truncated command:

The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM. However, certain settings such as username and password should not be distributed along with the pom.xml. This type of information should exist on the build server in the settings.xml.

epositories are declared inside a project, which means that if you have your own custom repositories, those sharing your project easily get the right settings out of the box. However, you may want to use an alternative mirror for a particular repository without changing the project files.

Some reasons to use a mirror are:

There is a synchronized mirror on the internet that is geographically closer and faster
You want to replace a particular repository with your own internal repository which you have greater control over
You want to run maven-proxy to provide a local cache to a mirror and need to use its URL instead

Proxies: This is basically used for proxies’ setup

The profile element in the settings.xml is a truncated version of the pom.xml profile element. It consists of the activation, repositories, pluginRepositories and properties elements. The profile elements only include these four elements because they concerns themselves with the build system as a whole (which is the role of the settings.xml file), not about individual project object model settings.

If a profile is active from settings, its values will override any equivalently ID’d profiles in a POM or profiles.xml file.

First Maven project?

To create our first Maven project we are going to use Maven’s archetype mechanism. An archetype is defined as an original pattern or model from which all other things of the same kind are made. In Maven, an archetype is a template of a project which is combined with some user input to produce a working Maven project that has been tailored to the user’s requirements.

On to creating your first project! In order to create the simplest of Maven projects, execute the following from the command line:

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DartifactId=my-app

Once you have executed this command, you will notice a few things have happened. First, you will notice that a directory named my-app has been created for the new project, and this directory contains a file named pom.xml that should look like this:

jar 1.0-SNAPSHOT
Maven Quick Start Archetype


pom.xml contains the Project Object Model (POM) for this project. The POM is the basic unit of work in Maven. This is important to remember because Maven is inherently project-centric in that everything revolves around the notion of a project. In short, the POM contains every important piece of information about your project and is essentially one-stop-shopping for finding anything related to your project.

This is a very simple POM but still displays the key elements every POM contains, so let’s walk through each of them to familiarize you with the POM essentials:

project: This is the top-level element in all Maven pom.xml files.
modelVersion: This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.

groupId: This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins.

artifactId: This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form -. (for example, myapp-1.0.jar).

packaging: This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). This not only means if the artifact produced is JAR, WAR, or EAR but can also indicate a specific lifecycle to use as part of the build process. (The lifecycle is a topic we will deal with further on in the guide. For now, just keep in mind that the indicated packaging of a project can play a part in customizing the build lifecycle.) The default value for the packaging element is JAR so you do not have to specify this for most projects.

version: This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.

name: This element indicates the display name used for the project. This is often used in Maven’s generated documentation.

url: This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation.

description: This element provides a basic description of your project. This is often used in Maven’s generated documentation.


Tagged : / / / / / / / / / / / / / /

Difference between Maven 1 and Maven 2 | Maven 1 Vs Maven 2


What is Maven 2?
Maven 2.0 is a complete rewrite of the ‘original’ Maven application (‘Maven 1’). As such, it is very different from Maven 1, and not backwards-compatible (eg, it cannot execute Maven 1 plugins). However, Maven 2.0 is the latest stable release of the Maven application, and new users are generally encouraged to use it for all new projects.
If you are familiar with Maven 1, you can find some information about moving to Maven 2 here or on the main Maven site.

Maven 1
To access the repository from your project, add the following line to your or

Maven 2
For Maven2, one needs to add the following into a project’s pom.xml, or into conf/settings.xml // (NOT in mirrors/mirror) where Maven2 is installed:

Maven 2 Lifecycles

Lifecycles are groupings of goals that define a process for building a project. Goals are bound to lifecycles to define a sequence that must be accomplished to produce results. Lifecycles ensure that users building projects with Maven only need to learn a small set of commands. Whereas Maven defines a default set of goals for each typical lifecycle, developers can bind additional goals to lifecycles to transparently add functionality to a build.
Typical lifecycles include:

  • compile—compile the source code
  • test—unit test the compiled source.

Note: Unit tests should not require the classes to be packaged or deployed.

  • package—bundle the compile and tested source code into a distributable package, such as a jar or war.
  • integration-test—employ the package as necessary and run integration tests.
  • install—install the package into the local repository. This allows the package to be utilized as a dependency of other projects.
  • deploy—copies the final package into the remote repositories for sharing and use with other projects.

As you can see, each lifecycle depends upon and builds upon the next. As a result, when a goal is bound to the compile lifecycle, all lifecycles will ensure its execution.
Lifecycles can be executed in conjunction with standalone goals. For instance, commonly the clean:clean goal is executed before the install goal. This is done by invoking:

m2 clean:clean install

Native Multiproject Support

One of the best practices that Maven strongly encourages is the idea that a single project should result in a single artifact, or package, being created. This best practice results in simplified builds and organized project structures. By natively supporting a hierarchical structure of projects, Maven now makes developing enterprise projects which implement this approach easier.
Maven 1 included a plugin for working with related of projects—or multiprojects. Maven 2 takes multiproject builds a step further by including a specialized parent descriptor and native multiproject execution support. As a result, any goals or lifecycles invoked upon a multiproject POM will result in each subproject goal being achieved.

Other Enhancements

Several other changes are included in Maven 2. Maven has been rewritten to be smaller and faster. The architectural changes make embedding Maven into other tools easier and allows for faster command line execution. Maven 2 depends upon fewer dependencies, resulting in a smaller distribution.
The way extensions are made to Maven has been changed in Maven 2. Instead, developers are encouraged to utilize JavaBeans for enhancements. Whereas scripting is allowed (through marmalade support—which includes a jelly facade), it is no longer the tool of choice. All extensions are made through the development of plugins (projects can no longer be customized through scripting in the maven.xml).
The introduction of a settings.xml file replaces the need for properties files. The settings file can be defined at a system, user, or project level. Settings are used to define private configuration information, including usernames and passwords. Project properties (including plugin configuration) are now all defined in the pom.xml.

Understanding Maven 2 Project Types

The first step to creating a maven project is determining which project template, or archetype, your Maven project should be configured as. Archetypes define which type of artifact will be produced by a project. Several archetype templates exist. The standard archetype will produce a standard library jar file. Templates also exist for webapps/wars, Maven plugin projects, documentation Web sites, and more.

Creating Project Descriptors

The archetype:create goal can be utilized to create a basic pom.xml for you project. This basic POM will allow you to execute all of the lifecycles and goals associated with any maven project. The archetype:create goal should be executed as follows:

m2 archetype:create -DgroupdId=com.daviddewolf.maven -DartifactId=example

This simple command creates the basic infrastructure needed for a project. It creates the pom.xml as well as the basic directory structure of for both source and test code. The following structure indicates the directories and files produced by issuing the archetype:goal command as listed above.

+ root
  - pom.xml
  + src
    + main
      + java
        + com
          + daviddewolf
            + maven
              + example
    + test
      + java
        + com
          + daviddewolf
            + maven
              + example

This simple structure that is created is enough to get started with Maven. All of the lifecycles now can be utilized. A simple invocation of the install lifecycle will compile, test, and package the application and then deploy it to the local system repository for use by other projects.
Once created, the POM can be customized to meet the requirements of the specific project. Documentation on the Maven POM can be found on the Maven2 Web site.

Goals You Should Know About

The introduction of lifecycles in Maven 2 has greatly reduced the number of goals that a developer must be aware of. Still, the following goals will undoubtedly be found useful (and can be utilized as soon as the basic descriptor has been generated).

  • clean:clean Clean all artifacts and intermediary files created by Maven
  • idea:idea Generate project files for the IntelliJ IDEA IDE
  • eclipse:eclipse Generate project files for the Eclipse IDE
  • javadoc:javadoc Generate the javadocs for the project
  • antrun:run Run a specified ant target
  • clover:clover Generate a coverage report for the project
  • checkstyle:checkstyle Generate a checkstyle report for the project
  • site:site Generate a documentation Web site for the project. This site will include many information reports concerning the project.

For more information concerning these and other goals, see the Maven2 Web site.
Learning Maven is not difficult; it simply requires a willingness to accept a new philosophy for building applications. Maven utilizes a a centralized project descriptor to intelligently build applications with prebuilt build tools. This differs greatly from ant and other build tools in that project developers are no longer required to write build systems by using a comprehensive set of utilities. This change will save development teams significant time and has started a revolution in build tools.
It is important to remember that Maven2 is still currently only released as Beta Software. Although it is mature enough to utilize in most projects, all of the Maven 1 plugins have not yet been migrated to Maven 2. With time, Maven 2 will become more widely accepted and the number of available plugins will grow beyond what is even available in Maven 1.

Tagged : / / / / / / / / / / / / / / / / /

How to Integrate Subversion Into Your Ant Build ? – Step by step guide


SVNAnt is an Ant task allowing you to interact with Subversion within the convenience of your Ant build script. No more writing custom scripts to get the revision of your repository to tag your release jars. Nor do you have to make command line calls to checkout your latest and greatest as part of your continuous integration process. With SVNAnt, you have the familiarity of the Ant syntax and the flexibility you need for interacting with Subversion.
SVNAnt is a full-featured Subversion client capable of using the native Java bindings or command-line wrappering depending on which is available. Beyond how it works, SVNAnt allows you to do all svn subcommands but the following:

blame cleanup help list
lock log merge propedit
proplist resolved unlocked  

If the svn subcommand is not listed here, you can use it in your Ant build file. Before we continue start using SVNAnt, we have to install it and configure Ant to use it.
Now that we know what SVNAnt is and what its features are, lets install SVNAnt so that you can begin to use SVNAnt to access Subversion within your Ant build cycle.

Step 1. (Download, Compile and Extract)
This step will download, compile, and “install” the latest version of SVNAnt.
1.1 Using Subversion, checkout the SVNAnt project located here:
1.2 From the command line, while inside of the location where you checked out SVNAnt to, run “ant makeDistrib”
1.3 Extract the .zip file created in the build directory of your SVNAnt source to a location of your choosing

Step 2. (Modify your build.xml)
The next step is to tell Ant how to find your SVNAnt task by adding the following to your build.xml file:
<path id= “svnant.classpath” >
<include name= “*.jar” />

<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”svnant.classpath” />
That should be it. I know that it appears to be too good to be true so lets verify this.

Step 3. (Verify installation)
Building upon Step 2, lets create a new ant task that will use the wcVersion feature of SVNAnt to get some information about your repository from a local working copy:
<target name=”testSVNAnt”>
<wcVersion path= “PATH/TO/YOUR/WORKINGCOPY” />

<echo message= “Subversion repository url: ${repository.url}” />
(Note: In the event that you need to pass credentials to Subversion, look here.)
The output should be something similar to this:
$ ant testSVNAnt

Buildfile: build.xml

[svn] <WcVersion> started …
[svn]  finished.
[echo] Subversion repository url:

Total time: 43 seconds

Pat yourself on the back. You have successfully installed SVNAnt and you are ready to implement Subversion into your Ant build cycle. Instead of us going through each available feature for SVNAnt, please view the SVNAnt Documentation. Now lets talk about why you may want to use SVNAnt to allow for Subversion interaction inside of your Ant build cycle.

Tagged : / / / / / / / / / / / / / / / /

Apache Ant – A Complete TASK Reference


Apache Ant Task: zip


Creates a zipfile.

The basedir attribute is the reference directory from where to zip.

Note that file permissions will not be stored in the resulting zipfile.

It is possible to refine the set of files that are being zipped. This can be done with the includes, includesfile, excludes, excludesfile and defaultexcludes attributes. With the includes or includesfile attribute you specify the files you want to have included by using patterns. The exclude or excludesfile attribute is used to specify the files you want to have excluded. This is also done with patterns. And finally with the defaultexcludes attribute, you can specify whether you want to use default exclusions or not. See the section on directory based tasks, on how the inclusion/exclusion of files works, and how to write patterns.

This task forms an implicit FileSet and supports all attributes of (dir becomes basedir) as well as the nested , and elements.

Or, you may place within it nested file sets, or references to file sets. In this case basedir is optional; the implicit file set is only used if basedir is set. You may use any mixture of the implicit file set (with basedir set, and optional attributes like includes and optional subelements like ); explicit nested elements so long as at least one fileset total is specified. The ZIP file will only reflect the relative paths of files within each fileset. The Zip task and its derivatives know a special form of a fileset named zipfileset that has additional attributes (described below).

The Zip task also supports the merging of multiple zip files into the zip file. This is possible through either the src attribute of any nested filesets or by using the special nested fileset zipgroupfileset.

The update parameter controls what happens if the ZIP file already exists. When set to yes, the ZIP file is updated with the files specified. (New files are added; old files are replaced with the new versions.) When set to no (the default) the ZIP file is overwritten if any of the files that would be added to the archive are newer than the entries inside the archive. Please note that ZIP files store file modification times with a granularity of two seconds. If a file is less than two seconds newer than the entry in the archive, Ant will not consider it newer.

The whenempty parameter controls what happens when no files match. If skip (the default), the ZIP is not created and a warning is issued. If fail, the ZIP is not created and the build is halted with an error. If create, an empty ZIP file (explicitly zero entries) is created, which should be recognized as such by compliant ZIP manipulation tools.

This task will now use the platform’s default character encoding for filenames – this is consistent with the command line ZIP tools, but causes problems if you try to open them from within Java and your filenames contain non US-ASCII characters. Use the encoding attribute and set it to UTF8 to create zip files that can safely be read by Java.

Starting with Ant 1.5.2, can store Unix permissions inside the archive (see description of the filemode and dirmode attributes for ). Unfortunately there is no portable way to store these permissions. Ant uses the algorithm used by Info-Zip’s implementation of the zip and unzip commands – these are the default versions of zip and unzip for many Unix and Unix-like systems.

Please note that the zip format allows multiple files of the same fully-qualified name to exist within a single archive. This has been documented as causing various problems for unsuspecting users. If you wish to avoid this behavior you must set the duplicate attribute to a value other than its default, “add”.


Attribute Description Required
destfile the zip-file to create. Exactly one of the two.
zipfile the deprecated old name of destfile. No
basedir the directory from which to zip the files. No
compress Not only store data but also compress them, defaults to true. Unless you set the keepcompression attribute to false, this will apply to the entire archive, not only the files you’ve added while updating. No
keepcompression For entries coming from existing archives (like nested zipfilesets or while updating the archive), keep the compression as it has been originally instead of using the compress attribute. Defaults false. Since Ant 1.6 No
encoding The character encoding to use for filenames inside the zip file. For a list of possible values see Defaults to the platform’s default character encoding. No
filesonly Store only file entries, defaults to false No
includes comma- or space-separated list of patterns of files that must be included. All files are included when omitted. No
includesfile the name of a file. Each line of this file is taken to be an include pattern No
excludes comma- or space-separated list of patterns of files that must be excluded. No files (except default excludes) are excluded when omitted. No
excludesfile the name of a file. Each line of this file is taken to be an exclude pattern No
defaultexcludes indicates whether default excludes should be used or not (“yes”/”no”). Default excludes are used when omitted. No
update indicates whether to update or overwrite the destination file if it already exists. Default is “false”. No
whenempty behavior when no files match. Valid values are “fail”, “skip”, and “create”. Default is “skip” No
duplicate behavior when a duplicate file is found. Valid values are “add”, “preserve”, and “fail”. The default value is “add”. No
roundup Whether the file modification times will be rounded up to the next even number of seconds.
Zip archives store file modification times with a granularity of two seconds, so the times will either be rounded up or down. If you round down, the archive will always seem out-of-date when you rerun the task, so the default is to round up. Rounding up may lead to a different type of problems like JSPs inside a web archive that seem to be slightly more recent than precompiled pages, rendering precompilation useless.
Defaults to true. Since Ant 1.6.2
comment Comment to store in the archive. Since Ant 1.6.3 No
level Non-default level at which file compression should be performed. Valid values range from 0 (no compression/fastest) to 9 (maximum compression/slowest). Since Ant 1.7 No



Zips all files in the htdocs/manual directory into a file called in the ${dist} directory. zips all files in the htdocs/manual directory into a file called in the ${dist} directory. If doesn’t exist, it is created; otherwise it is updated with the new/changed files.




Zips all files in the htdocs/manual directory. Files in the directory mydocs, or files with the name todo.html are excluded. Zips all files in the htdocs/manual directory. Only html files under the directory api are zipped, and files with the name todo.html are excluded.

excludes=”mydocs/**, **/todo.html”



Zips all files in the htdocs/manual directory, and also adds the file ChangeLog.txt in the current directory. ChangeLog.txt will be added to the top of the ZIP file, just as if it had been located at htdocs/manual/ChangeLog.txt. zips all files in the htdocs/manual directory into the docs/user-guide directory in the archive, adds the file ChangeLog27.txt in the current directory as docs/ChangeLog.txt, and includes all the html files in exampleszip under docs/examples. The archive might end up containing the files:


Code:: docs/user-guide/html/index.html


zips all files in the htdocs/manual directory into the docs/user-guide directory in the archive and includes all the files in any file that maches examples*.zip, such as all files within or Re-packages a TAR archive as a ZIP archive. If Unix file permissions have been stored as part of the TAR file, they will be retained in the resulting ZIP archive.






Apache Ant Task: Concat


Concatenates one or more resources to a single file or to the console. The destination file will be created if it does not exist. Since Ant 1.7.1, this task can be used as a Resource Collection that will return exactly one resource.


Attribute Description Required
destfile The destination file for the concatenated stream. If not specified the console will be used instead. No
append Specifies whether or not the file specified by ‘destfile’ should be appended. Defaults to “no”. No
force Specifies whether or not the file specified by ‘destfile’ should be written to even if it is newer than all source files. since Ant 1.6. Defaults to “yes”. No
encoding Specifies the encoding for the input files. Please see for a list of possible values. Defaults to the platform’s default character encoding. No
outputencoding The encoding to use when writing the output file since Ant 1.6. Defaults to the value of the encoding attribute if given or the default JVM encoding otherwise. No
fixlastline Specifies whether or not to check if each file concatenated is terminated by a new line. If this attribute is “yes” a new line will be appended to the stream if the file did not end in a new line. since Ant 1.6. Defaults to “no”. This attribute does not apply to embedded text. No
eol Specifies what the end of line character are for use by the fixlastline attribute. since Ant 1.6 Valid values for this property are:

  • cr: a single CR
  • lf: a single LF
  • crlf: the pair CRLF
  • mac: a single CR
  • unix: a single LF
  • dos: the pair CRLF

The default is platform dependent. For Unix platforms, the default is “lf”. For DOS based systems (including Windows), the default is “crlf”. For Mac OS, the default is “cr”.




Concatenate a string to a file: Concatenate a series of files to the console:

Hello, World!



Concatenate a single file, appending if the destination file exists: Concatenate a series of files, update the destination file only if is older that all the source files:






Concatenate a series of files, expanding ant properties Filter the lines containing project from build.xml and output them to report.output, prepending with a header




Lines that contain project


Concatenate a number of binary files.






Apache Ant Task: ReplaceRegExp


ReplaceRegExp is a directory based task for replacing the occurrence of a given regular expression with a substitution pattern in a selected file or set of files.The output file is only written if it differs from the existing file. This prevents spurious rebuilds based on unchanged files which have been regenerated by this task.


Attribute Description Required
file file for which the regular expression should be replaced. Yes if no nested is used
match The regular expression pattern to match in the file(s) Yes, if no nested is used
replace The substitution pattern to place in the file(s) in place of the regular expression. Yes, if no nested is used
flags The flags to use when matching the regular expression. For more information, consult the Perl5 syntax
g : Global replacement. Replace all occurrences found
i : Case Insensitive. Do not consider case in the match
m : Multiline. Treat the string as multiple lines of input, using “^” and “$” as the start or end of any line, respectively, rather than start or end of string.
s : Singleline. Treat the string as a single line of input, using “.” to match any character, including a newline, which normally, it would not match.
byline Process the file(s) one line at a time, executing the replacement on one line at a time (true/false). This is useful if you want to only replace the first occurrence of a regular expression on each line, which is not easy to do when processing the file as a whole. Defaults to false. No
encoding The encoding of the file. since Ant 1.6 No – defaults to default JVM encoding



Replaces occurrences of the property name “OldProperty” with “NewProperty” in a properties file, preserving the existing value, in the file ${src}/ This task supports a nested Regexp element to specify the regular expression. You can use this element to refer to a previously defined regular expression datatype instance.




This task supports a nested Substitution element to specify the substitution pattern. You can use this element to refer to a previously defined substitution pattern datatype instance. Replaces occurrences of the property name “OldProperty” with “NewProperty” in a properties file, preserving the existing value, in all files ending in .properties in the current directory






Replaces all whitespaces (blanks, tabs, etc) by one blank remaining the line separator. So with input Check that both files one.txt and two.txt are present otherwise the build will fail.



replaces all whitespaces (blanks, tabs, etc) by one blank remaining the line separator. So with input




would converted to









Apache Ant Task: Checksum


Generates checksum for files. This task can also be used to perform checksum verifications.

Note that many popular message digest functions – including MD5 and SHA-1 – have been broken recently. If you are going to use the task to create checksums used in an environment where security is important, please take some time to investigate the algorithms offered by your JCE provider. Note also that some JCE providers like the one by The Legion of the Bouncy Castle, the GNU project or the Technical University Graz offer more digest algorithms than those built-in into your JDK.

Warning: the case of the extension is that of the algorithm used. If you ask for “SHA1”, you get a .SHA1 extension; if you ask for “sha1”, you get a file ending in .sha1. The Java Crypto Engines are case-insensitive in matching algorithms, so choose a name to match your desired output extension, or set the fileext attribute.


Attribute Description Required
file The file to generate checksum for. One of either file or at least one nested (filesystem-only) resource collection.
todir The root directory where checksums should be written. No. If not specified, checksum files will be written to the same directory as the files themselves. since Ant 1.6
algorithm Specifies the algorithm to be used to compute the checksum. Defaults to “MD5”. Other popular algorithms like “SHA” may be used as well. No
provider Specifies the provider of the algorithm. No
fileext The generated checksum file’s name will be the original filename with the fileext added to it. Defaults to a “.” and the algorithm name being used. No
property This attribute can mean two different things, it depends on the presence of the verifyproperty attribute.
If you don’t set the verifyproperty attribute, property specifies the name of the property to be set with the generated checksum value.
If you set the verifyproperty attribute, property specifies the checksum you expect to be generated (the checksum itself, not a name of a property containing the checksum).
This cannot be specified when fileext is being used or when the number of files for which checksums is to be generated is greater than 1.
pattern Specifies the pattern to use as a pattern suitable for MessageFormat where {0} is replaced with the checksum and {1} with the file name. No – default is “{0}”.
format Specifies the pattern to use as one of a well-known format. Supported values are

name pattern description
CHECKSUM {0} only the checksum itself
MD5SUM {0} *{1} the format of GNU textutils md5sum
SVF MD5 ({1}) = {0} the format of BSDs md5 command
No – default is “CHECKSUM”.
totalproperty If specified, this attribute specifies the name of the property that will hold a checksum of all the checksums and file paths. The individual checksums and the relative paths to the files within the resource collections in which they are defined will be used to compute this checksum. (The file separators in the paths will be converted to ‘/’ before computation to ensure platform portability). since Ant 1.6 No
forceoverwrite Overwrite existing files even if the destination files are newer. Defaults to “no”. No
verifyproperty Specifies the name of the property to be set with “true” or “false” depending upon whether the generated checksum matches the existing checksum. When this is set, the generated checksum is not written to a file or property, but rather, the content of the file or property is used to check against the generated checksum. No
readbuffersize The size of the buffer (in bytes) to use when reading a file. Defaults to “8192” – you may get a better performance on big files if you increase this value. No



Generates a MD5 checksum for and stores the checksum in the destination file is overwritten only if is newer than itself. Generates a MD5 checksum for and stores the checksum in If already exists, it is overwritten.




Generates a MD5 checksum for and stores it in the Project Property foobarMD5. Generates a MD5 checksum for, compares it against and sets isMD5ok to either true or false, depending upon the result




Generates a SHA checksum for and stores the checksum in the destination file is overwritten only if is newer than itself. Generates a MD5 checksum for, compares it against the value of the property md5, and sets isEqual to either true or false, depending upon the result.




Works just like Example 1, but generates a .MD5 file for every file that begins with the name foo. Works like Example 4, but only sets isChecksumEqual to true, if the checksum matches – it will never be set to false. This example demonstrates use with the Condition task.





Apache Ant Task: Fail


Exits the current build (just throwing a BuildException), optionally printing additional information.The message of the Exception can be set via the message attribute or character data nested into the element.


Attribute Description Required
message A message giving further information on why the build exited No
if Only fail if a property of the given name exists in the current project No
unless Only fail if a property of the given name doesn’t exist in the current project No
status Exit using the specified status code; assuming the generated Exception is not caught, the JVM will exit with this status. Since Ant 1.6.2 No



Exit the current build with no further information given. Exit the current build and print something like the following to wherever your output goes:




build.xml:4: No message
build.xml:4: Something wrong here.
Exit the current build and print something like the following to wherever your output goes: Exit the current build and print something like the following to wherever your output goes:

Something wrong here.



build.xml:4: Something wrong here.
build.xml:2: unless=thisdoesnotexist
Using a condition to achieve the same effect Check that both files one.txt and two.txt are present otherwise the build will fail.




build.xml:2: condition satisfied



Tagged : / / / / / / / / / / / / / / /

Usage of ANT_OPTS in Ant Script | ANT_OPTS capabilities


Usage of ANT_OPTS in Ant Script | ANT_OPTS capabilities

Ant has three environment variables that you can use to set its default behavior.
• ANT_ARGS Set this variable to include those options you use frequently.
• ANT_OPTS is a list of arguments that you want to pass to the JVM that will run Ant.
• JAVACMD is the absolute path to the Java executable you want Ant to use. you may specify a value for the JAVACMD environment variable. This defaults to %JAVA_HOME%\bin\java, typically invoking the JVM provided in Sun’s Java Development Kit. Ant provides JAVACMD for those who wish to specify an alternate JVM. full path of the Java executable. Use this to invoke a different JVM than JAVA_HOME/bin/java(.exe).

These are useful environment variables that the Ant wrapper scripts use when
invoking Ant: ANT_OPTS and ANT_ARGS. Neither of these is typically set by users,
but each can provide value for certain situations.

The ANT_OPTS environment variable provides options to the JVM executing Ant,
such as system properties and memory configuration. ANT_OPTS – command-line arguments that should be passed to the JVM. For example, you can define system properties or set the maximum Java heap size here.

For authenticated proxy:
Set your ANT_OPTS environment variable to configure your proxy if you have one. For instance:
set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128

You can set these properties by either modifying Ant’s startup script, or by
using the ANT_OPTS environment variable. The following example shows the Windows commands to specify these properties using ANT_OPTS, and then to invoke Ant:
set ANT_OPTS=-DproxySet=true -DproxyHost=localhost -DproxyPort=80
ant mytarget
The same trick works on Unix, although the syntax is slightly different depending on which
shell you use:
$ export ANT_OPTS=”-DproxySet=true -DproxyHost=localhost -DproxyPort=80″
$ ant mytarget

set ANT_OPTS=-Dhttp.proxyHost=myproxyhost -Dhttp.proxyPort=8080 -Dhttp.proxyUserName=myproxyusername -Dhttp.proxyPassword=myproxypassword -Dhttps.proxyHost=myproxyhost -Dhttps.proxyPort=8080


Use ANT_OPTS to control Ant’s virtual machine settings.
Some tasks may require more memory, which you can set in the ANT_OPTS environment variable, using the appropriate mechanism for your platform:
set ANT_OPTS=-Xmx500M
export ANT_OPTS=-Xmx500M

Setting the maximum heap size is another common use of ANT_OPTS. Here is how we set the maximum size to 128 MB when using Sun’s JDK:
set ANT_OPTS=-Xmx128m

One environment variable you may wish to set is ANT_OPTS. The value of this variable is passed as a JVM argument. Specifying system properties is a common use. In this simple
example, we pass the log.dir system property to the JVM running Ant:
$ set ANT_OPTS=-Dlog.dir=C:\logs
$ ant run
Now this property is available within the buildfile, for instance:
<echo>Log directory is set to: ${log.dir}</echo>
If the buildfile runs a Java application, the property may be retrieved from within it as
String logDir = System.getProperty(“log.dir”);


Troubleshoot: Illegal Java options in the ANT_OPTS variable
The environment variable ANT_OPTS provides a means to pass options into Ant,
such as a permanent definition of some properties, or the memory parameters for
Java. The variable must contain only options the local JVM recognizes. Any invalid
parameter will generate an error message such as the following (where ANT_OPTS was
set to –3):
Unrecognized option: -3
Could not create the Java virtual machine.

If the variable contains a string that is mistaken for the name of the Java class to run
as the main class, then a different error appears:

Exception in thread “main” java.lang.NoClassDefFoundError: error-string
Test: Examine ANT_OPTS and verify that the variable is unset or contains valid
JVM options.
Fix: Correct or clear the variable.

Tagged : / / / / / / / / / / / / / / /