Maven is a project management and comprehension tool and as such provides a way to help with managing:
1) POM (Project Object Model) – The POM is the basic unit of work in Maven. 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. By default, the model version is set to 4.0.0.
• 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
• 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 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.
More information about POM files can be found in POM reference and POM Introduction.
2) Archetype – Archetype is a Maven project templating toolkit. It provides a standard way to enable creation of sample projects which can be used as a starting point.
• To create a maven project based on archetype, you need to give the following command:
• Following archetypes are provided by maven:
Archetype ArtifactIds Description
maven-archetype-archetype An archetype which contains a sample archetype.
maven-archetype-j2ee-simple An archetype which contains a simplifed sample J2EE application.
maven-archetype-mojo An archetype which contains a sample a sample Maven plugin.
maven-archetype-plugin An archetype which contains a sample Maven plugin.
maven-archetype-plugin-site An archetype which contains a sample Maven plugin site.
maven-archetype-portlet An archetype which contains a sample JSR-268 Portlet.
maven-archetype-quickstart An archetype which contains a sample Maven project.
maven-archetype-simple An archetype which contains a simple Maven project.
maven-archetype-site An archetype which contains a sample Maven site which demonstrates some of the supported document types like APT, XDoc, and FML and demonstrates how to i18n your site.
maven-archetype-site-simple An archetype which contains a sample Maven site.
maven-archetype-webapp An archetype which contains a sample Maven Webapp project.
• Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of archetype and a set of velocity templates which make up the prototype project. Archetype contents are as follows:
a) an archetype descriptor (archetype.xml in directory: src/main/resources/META-INF/maven/). It lists all the files that will be contained in the archetype and categorizes them so they can be processed correctly by the archetype generation mechanism.
b) the prototype files that are copied by the archetype plugin (directory: src/main/resources/archetype-resources/)
c) the prototype pom (pom.xml in: src/main/resources/archetype-resources)
d) a pom for the archetype (pom.xml in the archetype’s root directory).
See guide for creating archetype descriptors here for more information.
3) Build Lifecycle & Build Phases – Maven is based on concept of build lifecycle. This allows one to have a clearly defined process for building and distributing a particular artifact.
• There are three build lifecycles- default, clean and site. Default lifecycle is for handling project deployment, clean handles project cleanup and site handles the creation of project’s site documentation.
• Each of these lifecycles is made up of build phases. The build phase represents a stage in the lifecycle. eg. the default lifecycle is made up of following phases:
a) validate – validate the project is correct and all necessary information is available
b) compile – compile the source code of the project
c) test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
d) package – take the compiled code and package it in its distributable format, such as a JAR.
e) integration-test – process and deploy the package if necessary into an environment where integration tests can be run
f) verify – run any checks to verify the package is valid and meets quality criteria
g) install – install the package into the local repository, for use as a dependency in other projects locally
h) deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These phases (and other phases in clean and site phases) would be run sequentially. For example, if the following maven command is issued:
maven would do every build phase prior to compile before compile it (namely validate).
• A build phase is further made up of goals. Even though it may be responsible for a specific step in the build lifecycle, the manner in which it carries those responsibilities varies. This is achieved by declaring the goals bound to these build phases. A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.