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. The pom.xml file is the core of a project's configuration in Maven. It is a single configuration file that con-tains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively.

In the most basic form, a POM file has the following structure:

The following list contains explanation of POM’s elements:

• Project – this is top-level element in all maven pom.xml files;
• modelVersion – indicates which version of the object model this POM is using. The version of the model itself changes rarely 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 – indicates the unique identifier of the organization or group that created the project;
• artifactId – indicates the unique base name of the primary artifact being generated by this pro-ject. 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 would have the form -. (for example, myapp-1.0.jar);
• packaging – 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;
• version – indicates the version of the artifact generated by the project;
• name – indicates the display name used for the project;
• url – indicates where the project's site can be found;
• description - provides a basic description of the project.

POM file can be very complicated, since in can provide a lot of information. For clarification purposes it can be assumed, that the whole file can be decomposed into three different sections:

• project – related properties – provides information that precisely identify the project (also about developers, organisation, collaboration tools, etc.);
• process – related properties – defines how the build is performed (including definitions of plugins supporting different lifecycle phases and dependencies to be resolved by maven)
• environment – related properties – stores information about locations of build artifacts and de-pendencies of various types

Following list contains maven’s default lifecycle phases:

• Validate – validate the project is correct and all necessary information is available;
• Compile – compile the source code of the project;
• Test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed;
• Package - take the compiled code and package it in its distributable format, such as a JAR;
• Integration-test - process and deploy the package if necessary into an environment where inte-gration tests can be run;
• Verify - run any checks to verify the package is valid and meets quality criteria;
• Install - install the package into the local repository, for use as a dependency in other projects lo-cally;
• Deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

The following list of advices should help to avoid various problems which new Maven user may encounter.

• In order to avoid potential problems at the later stage of development it is recommended to install Maven in a path that does not contain any white spaces;

• It is recommended to include the following code analysis tools into the build lifecycle of all Java-based projects

1. Findbugs (link) - detects common bugs in the code using static code analysis

2. PMD (link) - also detects common errors in Java code

3. Cobertura (link) - generates reports showing which parts of code are covered with automated tests

4. Checkstyle (link) - it makes easier to use the same coding style across the project

• Developers should remove potential errors detected by FindBugs and PMD

• Whenever possible you should use general conventions described in Maven documentations, e.g., project folder structure

• When a particular maven plugin is used, you should specify its version number to avoid problems with broken builds resulted from errors introduced in newer versions of plugins;

• Each partner should setup its own Maven dependency repository, to make all necessary artifacts available through the local network – this should speed up build process. For more information refer to [pro].

• In order to stop Maven from checking for plugin updates (it may also speed up build process), you may use ”--o” parameter. It forces Maven to work offline.