A Birds’s Eye View of Maven

One of the things that we do on a daily basis is use Maven to build our projects by issuing build commands such as mvn install. Maven then looks at our project’s configuration file, affectionately known as a POM, magically figures out what do and, hey presto, your build is complete. I imagine that we do this so often that we never think about what’s going on behind the scenes, and in some cases without ever understanding what’s going on either. This blog takes a bird’s eye look at the Maven build lifecycle and reveals what happens when you issue commands such as mvn clean install.

If you’ve ever looked at the Maven documentation you’ll have read that Maven is all about a hierarchical object oriented build structure. In this there are three main artefacts: build life-cycles, build phases and goals, so a good place to start would be to explain the relationship between these terms. Take a look at the following UML diagram:

Jumping straight in, you can see that Maven HAS 1 one or more build life-cycles and each life-cycle HAS one or more build phases, which are executed in a given sequence. Likewise, each build phase has one or more build goals, which are also executed in a given sequence.

A good way of defining a build phase is to give an example. The Maven documentation lists what’s called the default life-cycle and here are its build phases:

  1. validate – validate the project is correct and all necessary information is available
  2. compile – compile the source code of the project
  3. test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  4. package – take the compiled code and package it in its distributable format, such as a JAR.
  5. integration-test – process and deploy the package if necessary into an environment where integration tests can be run
  6. verify – run any checks to verify the package is valid and meets quality criteria
  7. install – install the package into the local repository, for use as a dependency in other projects locally
  8. deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Hence, we can define a build phase as something that takes care of one part of a build life-cycle, for example compiling or testing your project.

You can tell Maven to build your project by specifying a build phase on the command line. For example:

mvn install

…means “carry out all build phases up to and including install phase in the default build life cycle”.
…whilst issuing a

mvn clean install

…means “carry all build phases of the clean life cycle up to and including the clean build phase and then carry out all build phases up to and including install phase in the default build life cycle”.

From this you can deduce that issuing a

mvn test

…command will carry out the validate build phase, executing its goals; then the compile phase, executing its goals and finally the test phase, executing its goals.

So, what are goals? In the Maven world a goal can be defined as a single task or job that actually does something concrete towards getting your project built. If we compare Maven to the company you probably work for, then the life-cycles would be the board of directors, the build phases the middle managers and the goals the workers who get the job done.

Most build phases come with default goals attached, for example the compiler build phase is bound, as you may have guessed, to the compiler:compile goal, and likewise the install build phase is bound to the install:install goal.

You can also bind your own goals to phases using the <plugin> element in your POM file, this can be used to either override a goal’s default behaviour or to add new goals and new behaviour.

A final point to note on goals is that they are usually associated with your POM’s package type. This makes sense as, for example, the compiler:compile goal is associated with jars and ejb packaging, but would be meaningless in terms of the POM, wars or ear packages.

In reading this, you may have gathered that by convention the names of goals contain a colon, whilst the names of build phases don’t. This allows you to specify goals on the Maven command line without confusing them with build phases. For example:

mvn compiler:compile 

…will carry out the compiler:compile goal, which is in the compiler build phase of the default build lifecycle. And, mixing things up at bit…

mvn install tomcat:redeploy

…will carry out all build phases up to and including install in the default build life cycle followed by the tomcat:redeploy goal found in the Tomcat Mojo.

And that’s the mile high, bird’s eye view of Maven.

1 HAS in the UML sense of the word.

Reference: A Birds’s Eye View of Maven from our JCG partner Roger Hughes at the Captain Debug’s Blog blog.

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

One Response to "A Birds’s Eye View of Maven"

  1. srinivas says:

    Very informational tid-bit. Thanks a lot.

Leave a Reply


4 − = zero



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books