Trying to Understand Maven

Firstly I would like to reiterate that I am no expert on theses topics and the main reason I Blog is to simply share with my fellow developers my though processes and things I pick up as I learn new technologies.

Your feedback is therefore most valued and appreciated. Today we will be looking at Maven, an amazing and “magical” technology (I think I might be shot for using the word “magical” ).

The Basics

Back in the day when we simply needed to create simple Java projects with very little library dependencies it was very simple, point to your JDK and import your required libraries. Off we would go coding our main class that would use other classes.

That was all and well (sometimes still a pain setting up the libraries though), but now what happens when we working on a bit larger project where we have much more external dependencies on libraries.  How do we link everything up?

Maven ( http://maven.apache.org/ ) has the answer to this (as well as the answer to some other issues as well.  In the words of the creators of Maven this is how they describe 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.”

That might sound a bit confusing but as we get into the features of Maven we will realise that it does in fact provide and promote a common build infrastructure. A list of Maven features include:

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

Project Object Model (POM)

I think the best way to explain how Maven achieves this is by introducing the Project Object Model (POM) file.  Since Maven 2 the project.xml has been renamed to pom.xml.

This pom.xml is where all the magic happens. Let us look at a sample POM file from Maven website:

xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0
 <groupId>com.mycompany.app
 <artifactId>my-app
 <packaging>jar</packaging>
 <version>1.0-SNAPSHOT</version>
 <name>Maven Quick Start Archetype</name>
 <url>http://maven.apache.org
 <dependencies>
 <dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>3.8.1</version>
 <scope>test</scope>
 </dependency>
 </dependencies>
</project>

I know it might seem a bit scary at first but this POM file really describes the essence of Maven and its ability to provide us with features such as build control to documentation management.

This is a copy of how Maven describes the common elements

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

If we look at the project or version elements we can see how this relates to releases and version control, whilst packaging relates to what type of output we would like Maven to output. Have a look at the above definitions and I hope this makes things a bit clearer as it has with me.

Thus far we have looked at some of the benefits / features of Maven and the POM file but not really spoken much about the actual framework and how it relates to our Java projects. That I will leave for my next post.

I hope this post gave you a brief introduction into Maven, the show is not yet over

Blog Soon!

Advertisement