Showing posts with label Maven POM. Show all posts
Showing posts with label Maven POM. Show all posts

What is Maven and How to install Maven?

MavenSW, located at http://maven.apache.org, is a great JavaSW project build and management tool from the ApacheSW Software Foundation. One primary focus of Maven is as a build tool, performing tasks similar to AntSW, although it's more like Ant on steroids.

A very significant aspect of Maven is the use of repositories to manage jarW files across different projects. In a simple software development environment, you may work on a project and check jar files directly into your project in your version control system, and you may do this in each project that you work on. This system works fine in relatively simple situations, but it becomes unweildy as projects grow in size, in complexity, and in their numbers of developers. In the Maven system, jar files are stored in remote repositories, and they are downloaded to your local machine to a local repository as needed. Typically, these same jar files are accessed across projects, and Maven makes it very simple to manage different versions of jar files, and to group together sets of related jar files. Building different types of projects (such as jars, wars, and ears) is handled very cleanly by Maven. Maven can perform tasks such as generate useful documentation about your project. The features of Maven go on and on.

Maven 2 is very significantly different from Maven 1. This tutorial will cover Maven 2.


To set up Maven, you need to:

  1. Download Maven and unzip it
  2. Create a JAVA_HOME System Variable
  3. Create an M2_HOME System Variable
  4. Add %JAVA_HOME%\bin;%M2_HOME%\bin; to your System Path

To begin with, download the latest Maven from http://maven.apache.org/download.html. I downloaded apache-maven-2.0.8-bin.zip and extracted it to C:\dev\apache-maven-2.0.8.\apache-maven-2.0.8.






apache-maven-2.0.8-bin.zip extracted to C:\dev\apache-maven-2.0.8

Go to your System Properties → Environment Variables.

Environment Variables

Create a JAVA_HOME System Variable and point it to your Java installation. I pointed mine to C:\dev\jdk1.6.0_04.

JAVA_HOME System Variable

Create an M2_HOME System Variable and point it to your Maven installation. I pointed mine to C:\dev\apache-maven-2.0.8.

M2_HOME System Variable

You should now have JAVA_HOME and M2_HOME System Variables.

System Variables

Add %JAVA_HOME%\bin;%M2_HOME%\bin; to your Path System Variable. This puts your Java and Maven executables in the System Path so that they can be executed without their fully qualified paths.

Adding %JAVA_HOME%\bin;%M2_HOME%\bin; to Path System Variable


Open a command prompt window, and at the command prompt, type 'mvn -version'. You should see a message displaying the version of MavenSW and the version of JavaSW.

'mvn -version' at command prompt

Next, at the command prompt, try typing a command like 'mvn clean'. You'll probably see that some jarW files downloaded from the Maven central repository to your machine. After that, we see a 'BUILD ERROR'. This message is fine. This is telling us that we ran the command but that there was no pom.xml file present in the directory where we ran the command.

'mvn clean'

After running the 'mvn clean', if we go to our user home directory (for me, C:\Users\Cakes), we can see that an .m2 directory has been created by mavenSW. Within .m2, we can see a 'repository' directory. This is the default location for your local maven repository. This local repository directory contains things such as the jar files that your projects use. In addition, it contains the jar files and things that maven itself needs. When we ran the 'mvn clean' command, we asked maven to do a 'clean' command, which requires the maven-clean-plugin jar file. If you look back at the command prompt output after the 'mvn clean' command, you can see that the maven-clean-plugin jar file was downloaded, since maven realized that it needed this jar file in order to do the 'clean'.

default .m2/repository created for local maven repository

If we examine the contents of our local maven repository, we can see that it contains the maven-clean-plugin jar file. On my machine, the jar is located at C:\Users\Cakes\.m2\repository\org\apache\maven\plugins\maven-clean-plugin\2.2.

local maven repository contains maven-clean-plugin

Our Maven is installed and working. We can now get to work creating projects with this great tool.





Click here to View more...

What is Maven?

Maven is a Java tool that builds and maintains project artefacts (like JAR, EAR or WAR files) from the source code and a project description file, called the POM (Project Object Model).

Maven, much like Ant, has the concept of goals, which correspond to build tasks that depend on the development lifecycle phase (compile, test, package, install, deploy, ...)
The most remarkable feature of Maven, though, is its management of project dependencies. The project POM defines a list of dependencies on artefacts from other projects (like Utility JARs for instance). These artefacts are stored in a central repository, and indexed by their groupId, artefactId and version.


When a developer wants to build a project, he/she doesn't need to worry about where to find the JARs that are required, as Maven will automatically retrieve those from the central repository of artefacts, and compile the project. The required list of JARs is taken from the POM dependency list.Better even, if those JARs in turn depend on other JARs, Maven will recursively descend the list of dependencies for those artefacts and bring them into the compilation environment.
See the
Maven website for more details.
Click here to View more...

Build Lifecycle

Maven 2.0 is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.
For the person building a project, this means that it is only necessary to learn a small set of commands to build any Maven project, and the POM will ensure they get the results they desired.
There are three built-in build lifecycles: default, clean and site. The default lifecycle handles your project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles the creation of your project's site documentation.
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):
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 integration 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 locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.
To do all those, you only need to call the last build phase to be executed, in this case, deploy:
mvn deploy
That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase. Thus, doing
mvn integration-test
will do every build phase before it (validate, compile, package, etc.), before executing integration-test.
There are more commands that are part of the lifecycle, which will be discussed in the following sections.
It should also be noted that the same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). For example:
mvn clean install
This command will traverse into all of the subprojects and run clean, then install (including all of the prior steps). Click here to View more...