Thursday, March 12, 2009

Maven: The Definitive Guide -- Book Review

Maven: The Definitive Guide by O'Reilly provides a great introduction to this increasingly ubiquitous development tool. Admittedly, this ubiquity is still perhaps limited to the Java open source community, but it's spreading fast, and with good reason. Many have knocked Maven for being overly complex, or over engineered, and I kept my distance for a while. I recently became more involved with the one of the Apache projects, Struts 2, and since that project, like most Apache projects by now, uses Maven, I decided to give it a good examination. Luckily, this new book had just came out and my introduction was eased greatly.

Star Rating: 4 out of 5 Stars

Maven: The Definitive Guide gets 4 out of 5 stars from me. This could have easily been 5 out of 5, but the code examples in the book have many errors. I'll say more about the code errors, and how to deal with them, in a later paragraph, but I don't want to start off on the wrong foot because I really like this book a lot. Let's focus on what it has to offer for now.

Introduction to Maven Space

The first six chapters of the book walk the reader from newbie to fully functional Maven developer in easy to follow, to the point manner. It really doesn't take long to read through these chapters, even doing the examples as you go. These chapters will show you how to structure, manage dependencies, build and release your projects "the Maven way". Rather than reproducing the content of the book, I'll just note a couple of more interesting aspects of the Maven way. Dependency management is one of the most dazzling features of Maven, so I'll start with that.

As an example, let's consider a project that depends upon Struts 2, a Struts 2 project in other words. How do you manage that dependency the Maven way? First, we have to understand how Maven identifies dependencies. Every project/artifact in the Maven universe is uniquely identified by a groupId, artifactId and version. This ternary identifier will become very familiar to you be the time you complete the first six chapters.

How does Maven go about finding the depencies then? All dependencies are Maven artififacts that are stored in repositories. There is a "mother" repository where all of the common Jar files of the Java world exist as Maven artifacts. Maven comes configured to point to the mother repository, located at Note, officially, this "mother" repository is called the "central" repository.

Take a couple of seconds to check this mother repo out. Here you'll see a directory structure that mirror's organization namespaces. Let's look for Struts 2. Tunnel down into org/apache/struts. The groupId for all of the struts stuff is org.apache.struts, and this is mirrored by the repository directory structure. The directories you now see are all of the artifactId's. You should see struts2-core; this is the main Struts 2 project, which happens to be packaged as a Jar file, like many Java projects. Inside of that directory you'll see a bunch of version numbers representing the different releases of that project. Let's look in 2.1.6, the most recent general release.

Looking inside that directory you'll see what first appears to be quite few items. Most of them are checksums however. In the end, you simply have:
  • The Jar file itself
  • The JavaDocs
  • The Source Code
  • The POM: the Maven descriptor file

And that's that. By the end of the first six chapters, you'll be more than familiar with all of this and you'll know that, with Maven, if you are creating a Struts 2 application, the only thing you'll need to do is declare that your project depends upon the struts2-core artifact by adding a line like the following to your projects own POM.


With this is place, you don't have to handle Jar files yourself. In a corporate setting, you can even configure your own repositories, but the main idea remains the same; you declare dependencies and let Maven do the actual management of physical jar files. Very nice.


These chapters will also show you how to use Maven archetypes to help get new projects up and running with a few key strokes. Archetypes provide the skeletal structure for a given type of project. Something like 90 archetypes are available in the default repository as we speak. These range from the standard Jar file type project, to generic web applications to very specific things like a Struts 2 archetype.

Reading Road Map

If you're looking for the shortest path to enlightenment, I can recommend the following reading path for this book. First, read chapters 1-6 in succession. They are short and will get you up to speed in a tutorial fashion. I think you can safely skip chapter 7, which shows a complicated real world project; you'll know if you need to read it.

Next, the reference section of the book has very good information. On first read, however, I think you are very safe in reading chapters 9, 10, and 14. 9 and 10 are essential descriptions of the POM itself and the way Maven actually works. Chapter 14 is an introduction to the eclipse plugin for Maven, m2eclipse. This plugin is a very powerful plugin that is not to be missed. As a teaser, I'll toss out one nice feature of using the Maven Eclipse plugin. When a Maven project, in Eclipse, references various dependencies, you can have Eclipse auto-magically get source code for all of those dependencies and link that source code into the Eclipse debugger and code awareness features. This means that you automatically get tracing and debugging into all of the open source Java projects that you work with, think Hibernate, Struts 2, etc.

A Word on the Book's Example Code

As I mentioned earlier, the example code simply has a lot of typo's and errors. Most of this stuff is already documented on the Sonatype web site.


I definitely recommend this book for any Java developer. In addition to the hard copy, you can also read the book online at the sonatype site, and it actually can be installed with the m2eclipse plugin so that you can read it within the help facilities of Eclipse. Cutting edge book distribution, eh? Enjoy.


Anonymous said...

Hello Mr. Davis,

I've been reading your fantastic Struts 2 in action book, and had a question. On page 263, the book states that the "naming convention of the XML validation metadata file is ActionClass-validations.xml". I got hung up on this for a while as I was using that naming convention for my validation files and it was not working. Then I noticed that the sample validation file in the text was named Register-validation.xml so I removed the s from my file names and validation worked in my app. I'm probably the only boob who's ever gotten hung up on that one line of text, but I thought I would point it out. Being new to the framework I just wanted to make sure that ...validations.xml is not the correct naming convention just to make sure I wasn't doing something else wrong. Sorry for going off topic on the blog post, but I couldn't find an email for you. Thanks for the great book!

Chad Davis said...

@ anonymous flatterer

First, thanks for the positive feedback about the book. It means a lot.

If you look closely at the text on page 263, you'll note that "ActionClass" is in italics -- that's a convention that means it should be read as literal.

Glad you figured it out though!

Chad Davis said...

BTW, the Manning site has a nice forum for discussing book issues like this. Often times other readers can answer the question quicker than I can.